GNOME Bugzilla – Bug 641082
Can't handle ECDSA keys
Last modified: 2016-07-07 18:48:06 UTC
openssh 5.7 has support for ECDSA keys. http://www.openssh.com/txt/release-5.7 when using such key, gnome-keyring can't unlock the key and ask for the passphrase. it doesn't catch the event to ask the passphrase and if ssh-add is used from terminal it gaves: ssh-add .ssh/alderaan_root Enter passphrase for .ssh/alderaan_root: Error reading response length from authentication socket. Could not add identity: .ssh/alderaan_root once i kill the ssh-agent started by gnome-keyring, i can use the newly key. Steps to reproduce: 1) ssh-keygen -t ecdsa 2) relogin and try to login to the remote server 3) notice that the passphrase is not asked via gnome-keyring 4) try to add using ssh-add
Any progress on this one? I think severity+1 would be appropriate. Regards, Gaute
Just make sure to actually find someone to do the work if you want increase the bug severity :P I spent an afternoon on it a while back, and it's on my list of things to work on. But certainly not happening in 3.4 because of lack of time. Sorry bout that.
Stef, Do you have a patch from your afternoon of time, even a broken one? I spent a few hours on this yesterday, but I'm pretty unfamiliar with all the codebases involved here, so didn't figure too much out... Thanks. -Chris
My first focus was trying to spend time figuring out how libgcrypt 'does' ECDSA. Including the S-expressions for the public and private keys, the DER formats that they're found in and so on. Also looked for examples of libgcrypt ECDSA usage, but couldn't find any. Anyway, getting this information together would be the first step. If you're interested, and willing to put in time to work on it, I can take some time to compile the locations where ECDSA would need to be added in order to get the ssh-agent and ssh-store working with it. LMK.
I did find this post, which looks modestly useful: http://lists.gnupg.org/pipermail/gcrypt-devel/2010-January/001564.html Let me try to figure out how much time I'll actually have available to work on this, and get back to you.
I've broken this up into various tasks that need to be done before ECDSA support makes it into gnome-keyring. I've added tasks into the depnedencies of this bug, and there is an entire tree here: https://bugzilla.gnome.org/showdependencytree.cgi?id=641082 Chris (or anyone else), if you have time to work on some of these steps, whether research or implementation, that would be really wonderful. The first research steps are: * Bug #672148 : Research: figure out how to do ECDSA with libgcrypt * Bug #672137 : Research: ASN.1 definitions for ECDSA * Bug #672139 : Research: Identify PKCS#11 ECDSA operations relevant to openssh
So, after doing a bit of research I've come to get a bit of feel for the patent uncertainty around ECC. My employer (Red Hat) does not ship ECC code due to the software patent claims on ECC. So for the time being I personally won't be investing time into adding ECC support to gnome-keyring's ssh-agent. That shouldn't prevent others from working on it. I've mapped out what needs to be done above, and in the linked bugs.
I would also like to see ECDSA support soon in gnome-keyring.
I would also enjoy ECDSA support in gnome-keyring as I always mistype my passphrases at login and if you do that enough with a host that's utilizing denyhosts you can get locked out! :D (In reply to comment #6) > https://bugzilla.gnome.org/showdependencytree.cgi?id=641082 I've a novice to gnome-keyring and cryptography; I'll see how I can help.
*** Bug 693059 has been marked as a duplicate of this bug. ***
I can successfully SSH login with an ecdsa key by manually enter the password ... Yet, I want to add it to Gnome Keyring via 'ssh-add /path/to/privid' and I always get the following error message 'Error reading response length from authentication socket.' Is there any progress with this bug?
I got it running by doing the following steps. Which doesn't solve the issue, but helps as a workaround: $ echo $SSH_AUTH_SOCK /run/user/1000/keyring-goxqaf/ssh $ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-CkimhXH5DSM/agent.5447; export SSH_AUTH_SOCK; SSH_AGENT_PID=5448; export SSH_AGENT_PID; echo Agent pid 5448; Now copy the "SSH_AUTH_SOCK=/tmp/ssh-CkimhXH5DSM/agent.5447" part and enter: $ SSH_AUTH_SOCK=/tmp/ssh-CkimhXH5DSM/agent.5447 Then you are able to add the ECDSA key (not to Gnome Keyring) to the SSH agent. Those IDs might change. Therefore, it's not recommended for daily use.
(In reply to comment #12) > I got it running by doing the following steps. Which doesn't solve the issue, > but helps as a workaround: > > …etc… > > Then you are able to add the ECDSA key (not to Gnome Keyring) to the SSH agent. > Those IDs might change. Therefore, it's not recommended for daily use. The usual method for doing this is one of: eval $(ssh-agent) exec ssh-agent bash …or disabling "gnome-keyring-ssh.desktop" in XDG Autostart. But, of course, it doesn't help people who specifically want to use GNOME Keyring, which is what this bug report is all about.
(In reply to comment #7) > So, after doing a bit of research I've come to get a bit of feel for the patent > uncertainty around ECC. > > My employer (Red Hat) does not ship ECC code due to the software patent claims > on ECC. So for the time being I personally won't be investing time into adding > ECC support to gnome-keyring's ssh-agent. Is this still the case? Fedora does ship with ECDSA support. If it had patent issues I'd imagine redhat would remove it from Fedora, no?
You're right. The situation has indeed changed. I simply haven't had time to work on this. Work on gnome-keyring is done in my (very little) free time. Personally, I would like to find a way to call into the openssh ssh-agent rather than reimplement the all the new algorithms. But open to contributions either way.
Maybe just import the necessary files from OpenSSH, as pam_ssh is doing? ECDSA is one thing, but now there's also a whole new key storage format which it uses for Ed25519 (and optionally other types), which is even more work.
Yes, exactly Ed25519 is what removed the doubt any doubt in my mind that I don't want to be maintaining a whole reimplemented ssh agent. I don't think copying over files from OpenSSH would be easy, but I wouldn't be against someone stepping up to do that and maintaining it.
Stef, if you'd looking for funding to complete this work, I would be happy to provide it.
Some work on this in the ssh-wip git branch.
Great news about the wip! I will have a look at it. On Seahorse side, I've opened a bug as the support is missing as well. (https://bugzilla.gnome.org/show_bug.cgi?id=754028) And a patch has been proposed.
The main issue I'm having is the lack of available documentation to get gnome-keyring to step aside and just depend on ssh-agent for this. Comment 13 is partly helpful, but after a reboot ssh-agent isn't running so it's not a persistent fix. I opened bug 761896 to hopefully get the wiki updated since it contains stale information on how to do this.
(In reply to Chris Murphy from comment #21) > The main issue I'm having is the lack of available documentation to get > gnome-keyring to step aside and just depend on ssh-agent for this. This is the most durable why I've found: mkdir -p ~/.config/autostart cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/ echo "X-GNOME-Autostart-enabled=false" >> ~/.config/autostart/gnome-keyring-ssh.desktop Upstart session jobs honour the X-GNOME-Autostart-enabled=false flag, as does the xdg/autostart stuff, but you do seem to need all the fields filled to ensure that the local autostart desktop file takes precedence over the system wide one.
(In reply to Stef Walter from comment #17) > Yes, exactly Ed25519 is what removed the doubt any doubt in my mind that I > don't want to be maintaining a whole reimplemented ssh agent. > > I don't think copying over files from OpenSSH would be easy, but I wouldn't > be against someone stepping up to do that and maintaining it. Any reason not to just proxy directly to the OpenSSH ssh-agent binary?