After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 641082 - Can't handle ECDSA keys
Can't handle ECDSA keys
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: ssh-agent
3.2.x
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
: 693059 (view as bug list)
Depends on: 672140 672144 672145 735873
Blocks:
 
 
Reported: 2011-01-31 22:06 UTC by Ionut Biru
Modified: 2018-03-06 22:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patche-set to support ECDSA in gnome-keyring (159.23 KB, patch)
2017-08-16 08:20 UTC, Jakub Jelen
none Details | Review

Description Ionut Biru 2011-01-31 22:06:09 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
Comment 1 Gaute Hope 2012-03-01 11:18:03 UTC
Any progress on this one? I think severity+1 would be appropriate.

Regards, Gaute
Comment 2 Stef Walter 2012-03-01 13:02:15 UTC
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.
Comment 3 Chris Danis 2012-03-13 14:34:00 UTC
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
Comment 4 Stef Walter 2012-03-13 20:50:02 UTC
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.
Comment 5 Chris Danis 2012-03-14 00:58:45 UTC
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.
Comment 6 Stef Walter 2012-03-15 14:50:38 UTC
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
Comment 7 Stef Walter 2012-03-31 20:37:14 UTC
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.
Comment 8 Alexander E. Fischer 2012-11-08 18:20:08 UTC
I would also like to see ECDSA support soon in gnome-keyring.
Comment 9 Winston Weinert 2012-12-08 21:55:22 UTC
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.
Comment 10 Stef Walter 2013-02-04 21:22:52 UTC
*** Bug 693059 has been marked as a duplicate of this bug. ***
Comment 11 t.ask 2013-12-31 17:13:55 UTC
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?
Comment 12 t.ask 2013-12-31 17:26:58 UTC
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.
Comment 13 Mantas Mikulėnas (grawity) 2013-12-31 17:46:08 UTC
(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.
Comment 14 Elad Alfassa 2014-06-05 22:28:30 UTC
(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?
Comment 15 Stef Walter 2014-06-06 05:30:31 UTC
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.
Comment 16 Mantas Mikulėnas (grawity) 2014-06-06 05:35:55 UTC
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.
Comment 17 Stef Walter 2014-06-06 05:38:35 UTC
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.
Comment 18 David Strauss 2014-07-10 19:00:59 UTC
Stef, if you'd looking for funding to complete this work, I would be happy to provide it.
Comment 19 Stef Walter 2014-08-29 13:36:52 UTC
Some work on this in the ssh-wip git branch.
Comment 20 Jean-Christophe Berthon 2015-09-05 18:37:20 UTC
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.
Comment 21 Chris Murphy 2016-02-12 07:53:24 UTC
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.
Comment 22 John Morton 2016-06-09 02:46:03 UTC
(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.
Comment 23 John Morton 2016-06-09 03:08:46 UTC
(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?
Comment 24 Martin Wilck 2016-08-12 09:26:31 UTC
Changing the configuration to prefer genuine ssh-agent over gnome-keyring-daemon has become even more complicated in F24 due to default activation of gnome-keyring-pam. A full walkthrough can be found here:

https://ask.fedoraproject.org/en/question/92448/how-do-i-get-proper-ssh-agent-functionality-in-gnome/
Comment 25 Mantas Mikulėnas (grawity) 2016-08-12 09:47:41 UTC
(In reply to Martin Wilck from comment #24)
> Changing the configuration to prefer genuine ssh-agent over
> gnome-keyring-daemon has become even more complicated in F24 due to default
> activation of gnome-keyring-pam. A full walkthrough can be found here:
> 
> https://ask.fedoraproject.org/en/question/92448/how-do-i-get-proper-ssh-
> agent-functionality-in-gnome/

Even though g-k-d is *started* via PAM, I don't think it actually updates the *environment* until much later (i.e. when the ssh module is initialized); does it? Disabling the .desktop file seems to work well here.
Comment 26 Martin Wilck 2016-08-12 13:09:04 UTC
The environment has to be set early on to affect the entire session. pam_gnome_keyring.so does it in the start_daemon() function right after starting the daemon.
Comment 27 Mantas Mikulėnas (grawity) 2016-08-12 14:00:11 UTC
(In reply to Martin Wilck from comment #26)
> The environment has to be set early on to affect the entire session.

Doesn't mean a .desktop service cannot do it. gnome-session has a separate stage and DBus API just for that.

> pam_gnome_keyring.so does it in the start_daemon() function right after
> starting the daemon.

But it only receives SSH_AUTH_SOCK in the first place if it was told to also initialize the daemon, which AFAIK is usually deferred.
Comment 28 Martin Wilck 2016-08-12 14:18:31 UTC
(In reply to Mantas Mikulėnas from comment #27)
> > pam_gnome_keyring.so does it in the start_daemon() function right after
> > starting the daemon.
> 
> But it only receives SSH_AUTH_SOCK in the first place if it was told to also
> initialize the daemon, which AFAIK is usually deferred.

Right, I didn't realize that. I had been going crazy trying to figure out how gnome-keyring-daemon had been started that once I found it, I was certain this was the thing to change ...

So, you're right, the step disabling g-k-d autostart can be skipped in my howto. I'm going to fix that.
Comment 29 Evan Klitzke 2016-09-02 20:00:27 UTC
I don't understand the intricacies of gnome-session, but my understanding is that this could work something like this:

 * systemd starts ssh-agent as a user unit
 * gnome-session imports SSH_AUTH_SOCK from systemd
 * the SSH_AUTH_SOCK propagates to the user environment

The systemd user sessions will do the right thing with killing the ssh-agent process on logout (or keeping it alive if session "lingering" is enabled).

I am doing something similar to this now, I wrote a small guide at https://eklitzke.org/using-ssh-agent-and-ed25519-keys-on-gnome . This would definitely be cleaner though with tighter integration between gnome-session and systemd.
Comment 30 Martin Wilck 2016-09-09 11:14:59 UTC
(In reply to Evan Klitzke from comment #29)
Cool, but what exactly is the advantage compared to the pam-ssh approach?
Comment 31 1d28ed33 2017-03-04 21:43:18 UTC
This issue is ugly and should really be fixed…

We have 2017 now and still no ED25519 support in GNOME's keyring?!
I would have expected this to ship with Debian 9 at most, but this might be too late now. Anyway, implementing this is in some way really a security improvement, because actually when you have multiple working identities for a server (RSA & ED25519), which might be common for compatibility reasons, GNOME's ssh actually selects the RSA one and unless the user has different passwords set for the keys, he/she will never notice it.
This means GNOME may downgrade the security without any user feedback while users think ssh always uses the "best" key available.

FYI when only ED25519 is available GNOME'S ssh-agent falls back to the default ssh-agent, which supports ED25519 keys.

https://bugzilla.gnome.org/show_bug.cgi?id=672145 is also about this issue.
This is a repost from https://bugzilla.gnome.org/show_bug.cgi?id=723274#c8.
Comment 32 André Klapper 2017-03-05 00:17:51 UTC
If someone would like to see this and provide a patch, please see
https://wiki.gnome.org/Git/Developers#Contributing_patches - thanks!
Comment 33 Jakub Jelen 2017-08-16 08:20:44 UTC
Created attachment 357692 [details] [review]
Patche-set to support ECDSA in gnome-keyring

Hello all,
I am attaching the patch-set which adds a support for ECDSA to gnome-keyring. It is also covering some test cases more or less related to the ECDSA keys handling. The changes can be visible also on the github [1].

First 7 commits are not mandatory for the functionality, but allows strict builds and fix several typos. The later 10 commits are gradually adding this functionality all over the gnome-keyring up to the ssh-agent.

It looks like we are late for 3.25 [2], but it would be great if we could get it in the next release, because this is a common problem that many people around struggle and stop using gnome-keyring.

[1] https://github.com/GNOME/gnome-keyring/compare/master...Jakuje:ecdsa-support
[2] https://wiki.gnome.org/Schedule
Comment 34 Daiki Ueno 2017-09-22 14:35:30 UTC
I took liberty to push the first 7 commits as they look obvious and are orthogonal to this bug.  I am not sure about the latter 10 commits (especially the last 7 commits), though.  

As far as I understand it, the suggestion was to launch the ssh-agent program from OpenSSH as a subprocess (bug 775981, and the ssh-wip branch mentioned in comment 19), rather than having the complete implementation of ECDSA in the library.  Is there any obstacle towards that?
Comment 35 Jakub Jelen 2017-09-22 14:52:21 UTC
Thank you Daiki.
I liked in the gnome-keyring that idea that it stores all (even OpenSSH) keys itself in secure location, rather than it would just forward the communication/data to the ssh-agent itself, without simply knowing what is that process doing with sensitive data. I didn't investigate the forwarding option deeply (well ... why then even run the gnome-keyring, when I can run the ssh-agent directly?).
Also gnome-keyring should not be only about ssh-keys as it was designed (but I am not sure if there are currently some other uses) so the support for ECDSA in the library itself can have wider use.

Choosing which approach is gnome-keyring going to take is probably maintainers task but it looks like Stef was inclining to the forwarding option for some reason (even though you can find also his tracking bugs for the ECDSA implementation).
Comment 36 Michael Catanzaro 2017-09-22 16:49:01 UTC
(In reply to Jakub Jelen from comment #35)
> Thank you Daiki.
> I liked in the gnome-keyring that idea that it stores all (even OpenSSH)
> keys itself in secure location

(Note that gnome-keyring's use of secure memory has been broken for at least four or five years.)
Comment 37 Daiki Ueno 2017-09-25 10:51:09 UTC
(In reply to Jakub Jelen from comment #35)

> I didn't investigate the forwarding
> option deeply (well ... why then even run the gnome-keyring, when I can run
> the ssh-agent directly?).

Though I neither see much sense in that (now that the gpg-agent code has been removed), I guess we would still need to wrap ssh-agent somewhere to preserve the same UX: redirect the password prompt to gnome-shell and automatically load the private keys.
Comment 38 Daiki Ueno 2017-10-18 09:16:59 UTC
In any case, as the majority of the patches are for adding ECDSA in PKCS#11, I have pushed the patches to the git master.
Comment 39 Evan Klitzke 2017-10-22 11:16:22 UTC
Jakub,

This is really amazing, thanks for this work! I would like to test this change to confirm it works for me. What's the best way? I'm currently on the Fedora 27 beta (and dnf shows me that I have gnome-keyring 3.20.1-3.fc27). Should I build gnome-keyring from source, or should I expect an RPM to work for me?

Regards,
Evan
Comment 40 Jakub Jelen 2017-10-23 07:55:20 UTC
Evan, this change will most probably not get into Fedora 27 so you would have to build gnome-keyring from source, from master or just rebuild the latest Fedora package with the bunch of patches that get applied in upstream git.

To simplify that also for others who would like to submit feedback before getting the full update from GNOME, I put together a copr repository with these patches (as applied upstream + workaround for Fedora 25, which does not have SHA384 in glib):
https://copr.fedorainfracloud.org/coprs/jjelen/gnome-keyring-ecdsa/
Comment 41 Daniel Serodio 2017-10-30 20:58:13 UTC
It's been a while since I've used this Bugzilla so please forgive the question: which GNOME release contains (will contain?) this fix?
Comment 42 Peter Lawler 2017-10-30 21:16:05 UTC
(In reply to Daniel Serodio from comment #41)
> It's been a while since I've used this Bugzilla so please forgive the
> question: which GNOME release contains (will contain?) this fix?

https://duckduckgo.com/?q=fedora+27+gnome+version
https://wiki.gnome.org/Schedule
Suggests to me the answer to your question is 3.27
Comment 43 Michael Catanzaro 2017-10-30 22:40:30 UTC
gnome-keyring is unmaintained, so I doubt there are any plans to release a new version with this fix. This would be good to discuss in #gnome-hackers; maybe somebody there would be willing to step up and do a new release.
Comment 44 Daiki Ueno 2017-10-31 08:46:34 UTC
As we are still early in the 3.27 development cycle, it would be good to start testing this new feature.  If nobody minds, I am going to create 3.27.2 by the tarballs due.
Comment 45 Michael Catanzaro 2017-10-31 15:18:27 UTC
Go ahead, thank you Daiki!
Comment 46 Evan Klitzke 2017-10-31 16:11:58 UTC
(In reply to Jakub Jelen from comment #40)
> Evan, this change will most probably not get into Fedora 27 so you would
> have to build gnome-keyring from source, from master or just rebuild the
> latest Fedora package with the bunch of patches that get applied in upstream
> git.
> 
> To simplify that also for others who would like to submit feedback before
> getting the full update from GNOME, I put together a copr repository with
> these patches (as applied upstream + workaround for Fedora 25, which does
> not have SHA384 in glib):
> https://copr.fedorainfracloud.org/coprs/jjelen/gnome-keyring-ecdsa/

Jakub,

I enabled your COPR and am having some issues:

$ env | grep SSH
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

$ sudo lsof -p 2809
COMMAND    PID USER   FD      TYPE             DEVICE  SIZE/OFF    NODE NAME
gnome-key 2809 evan  cwd       DIR              253,1      4096       2 /
gnome-key 2809 evan  rtd       DIR              253,1      4096       2 /
gnome-key 2809 evan  txt       REG              253,1   1128984 1451399 /usr/bin/gnome-keyring-daemon
...
gnome-key 2809 evan   11u     unix 0xffff9b2117645400       0t0   46752 /run/user/1000/keyring/ssh type=STREAM
...

$ ls -l /run/user/1000/keyring/ssh
srwxr-xr-x 1 evan evan 0 Oct 31 12:04 /run/user/1000/keyring/ssh

$ ssh-add -l
The agent has no identities.

$ ssh-add
Enter passphrase for /home/evan/.ssh/id_ed25519: 
Could not add identity "/home/evan/.ssh/id_ed25519": communication with agent failed

Do you have any ideas? I can also take this 1:1 over email or on the Fedora bugzilla.
Comment 47 Jakub Jelen 2017-11-02 19:38:38 UTC
Evan, this bug is about ECDSA keys. We did not touch ED25519, mainly because there is no specification for this type of keys in underlying PKCS#11 layer (and it is tracked in separate bugs such as #723274.