GNOME Bugzilla – Bug 550736
Cannot Import Public SSH Keys
Last modified: 2018-08-03 19:11:57 UTC
In Seahorse you can delete public ssh keys, and you can copy them, but you can't import them or paste them from the clipboard. As far as I know there isn't any other graphical way to add manage your ssh keys and since seahorse already allows deleting and copying it seems like pasting and importing would be a natural fit.
The copying public ssh key feature was fixed as part of bug https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/230537
I guess this should be marked fixed. ie: Adam's fix.
Should it remain open for the importing feature though?
Sorry I was confusing, the importing feature was what I was talking about. I just posted that first comment because I thought some people might not know that the copying feature was already added.
Yes I guess this may need to be reworked. I've actually been thinking about how the paste and import currently works. It uses gvfs to detect the mimetype of the data. While that sort of works, it'd probably be better to allow the different components (PGP, SSH etc...) to register their own internal mimetype detectors within seahorse so we can handle corner cases, or cases that are expected to always work.
Confirming that importing public SSH RSA keys still does not work in seahorse 3.4.1-2 in Debian. Either by importing them through the "File>Import" menu item, or by dragging the public key file in seahorse's window. I get this error message: "Cannot display a file of this type" Since seahorse is meant to make managing the user's encryption keys easier, I think importing SSH keys is a must-have feature. I often do some remote maintenance on friends' computers and that would save them the trouble from opening a terminal, and typing 'curl http://some.keyserver.com/mykey.pub >> ~/.ssh/authorized keys', which is unintuitive and hard to understand for them. By importing the keys (drag and drop would be great) to seahorse they could easily understand the public key principle, and visualize who's authorized to access their computer.
*** Bug 617770 has been marked as a duplicate of this bug. ***
For what it's worth, importing a SSH key in Debian Wheezy's Seahorse (3.4.1-2) almost works (I'm asked the passphrase and a label) but fails with "no user has logged in". See complete bug report at http://bugs.debian.org/699052.
I could reproduce this bug on Fedora 18 Live: - Importing a SSH public key returns: "Cannot display a file of this type." error message. - Importing a SSH private key returns: "No user has logged in." after being asked for the passphrase and a label.
I've taken a cursory look through the source of seahorse and gcr. For the public key import, the error message is produced in gcr. gcr_failure_renderer_new_unsupported is called by on_parser_parsed, by parsed_fire, by multiple parser functions: parser_normal/parser_formats. I don't see a pkcs11 parser, but there is an openssh parser. Though I have yet to completely map out the codepaths I imagine the fix would entail figuring out why public keys aren't matched to any parser, and maybe writing a parser for them. In 2008 Stef wrote: (In reply to comment #5) > Yes I guess this may need to be reworked. I've actually been thinking about how > the paste and import currently works. > > It uses gvfs to detect the mimetype of the data. While that sort of works, it'd > probably be better to allow the different components (PGP, SSH etc...) to > register their own internal mimetype detectors within seahorse so we can handle > corner cases, or cases that are expected to always work. I imagine that this mechanism to properly parse/import data based on standards is what drove the creation of gcr in 2009, so this idea of allowing components to register their own mimetype detectors is outdated. Stef? ___ As for the private key import failure, seahorse calls out to gcr which propagates an error ("No user has logged in.") from p11-kit. The fix for this would require digging into these codebases to see what is causing this error.
*** Bug 689005 has been marked as a duplicate of this bug. ***
After some changes in the code between 2013-04 and 2013-07 importing a SSH private key no longer fails with: "No user has logged in." Instead, it imports to the old ~/.gnome2/keyrings folder as a pkcs8 file. Making gnome-keyring import to ~/.ssh/ for SSH Keys requires adding write capabilities to the gnome-keyring PKCS#11 ssh-store module. I'll create a new bug in gnome-keyring for this issue. https://bugzilla.gnome.org/show_bug.cgi?id=705225 Also, according to https://wiki.gnome.org/GnomeKeyring/Architecture gnoem-keyring requires each private key to have a public key with *.pub extension. However, gcr-parser.c has a parse_openssh_public function already, so there is more investigation to be done.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/seahorse/issues/22.