gnome-keyring doesn't support ecdsa or ed25519 keys

Bug #771272 reported by Claudio Moretti on 2011-04-26
376
This bug affects 81 people
Affects Status Importance Assigned to Milestone
GNOME Keyring
Confirmed
Wishlist
gnome-keyring (Debian)
Confirmed
Unknown
gnome-keyring (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: gnome-keyring

I'm not sure I have described it correctly in the summary, but this is what happens:
I run ssh-add in a new terminal and enter my passphrase, which is the same for my DSA and ECDSA key: the DSA identity is added, but the ECDSA gets the "Error reading response length from authentication socket. Could not add identity: /home/claudio/.ssh/id_ecdsa" error.
I run ssh-agent, copy and paste the output in the terminal and re-run ssh-add. Both identities are correctly added:
============================================================================
claudio@Chuck:~$ ssh-add
Enter passphrase for /home/claudio/.ssh/id_dsa:
Identity added: /home/claudio/.ssh/id_dsa (/home/claudio/.ssh/id_dsa)
Error reading response length from authentication socket.
Could not add identity: /home/claudio/.ssh/id_ecdsa
claudio@Chuck:~$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-szGWMUbE3916/agent.3916; export SSH_AUTH_SOCK;
SSH_AGENT_PID=3917; export SSH_AGENT_PID;
echo Agent pid 3917;
claudio@Chuck:~$ SSH_AUTH_SOCK=/tmp/ssh-szGWMUbE3916/agent.3916; export SSH_AUTH_SOCK;
claudio@Chuck:~$ SSH_AGENT_PID=3917; export SSH_AGENT_PID;
claudio@Chuck:~$ echo Agent pid 3917;
Agent pid 3917
claudio@Chuck:~$ ssh-add
Enter passphrase for /home/claudio/.ssh/id_dsa:
Identity added: /home/claudio/.ssh/id_dsa (/home/claudio/.ssh/id_dsa)
Identity added: /home/claudio/.ssh/id_ecdsa (/home/claudio/.ssh/id_ecdsa)
============================================================================
Here is the content of my ~/.ssh/

claudio@Chuck:~$ ls -l .ssh
total 32
-rw-r--r-- 1 claudio claudio 726 2011-04-15 23:34 config
-r-------- 1 claudio claudio 751 2011-04-05 10:35 id_dsa
-rw-r--r-- 1 claudio claudio 603 2011-04-05 10:34 id_dsa.pub
-r-------- 1 claudio claudio 444 2011-04-05 10:29 id_ecdsa
-rw-r--r-- 1 claudio claudio 267 2011-04-05 10:23 id_ecdsa.pub
-rw------- 1 claudio claudio 6402 2011-04-19 18:04 known_hosts
-rw-r--r-- 1 claudio claudio 2760 2011-04-06 17:05 known_hosts.old

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: gnome-keyring 2.92.92.is.2.32.1-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Tue Apr 26 16:27:02 2011
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-keyring
UpgradeStatus: Upgraded to natty on 2011-04-03 (23 days ago)

Claudio Moretti (flyingstar16) wrote :
Jonathan Hudson (jh+lpd) wrote :

Don't think it's that simple. The new agent is overriding the gnome authentication agent, and you've now lost any keys that were automagically loaded from the gnome keyring.

This is a very annoying bug, possibly in /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1.

Please can it be fixed soon.

On Wed, Apr 27, 2011 at 13:53, jh <email address hidden> wrote:

> Don't think it's that simple. The new agent is overriding the gnome
> authentication agent, and you've now lost any keys that were
> automagically loaded from the gnome keyring.
>
> Ah, now I understand:

claudio@Chuck:~$ echo $SSH_AUTH_SOCK
/tmp/keyring-ZK6XAP/ssh
claudio@Chuck:~$ echo $SSH_AGENT_PID
1640
claudio@Chuck:~$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-iRQvNKEv2225/agent.2225; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2226; export SSH_AGENT_PID;
echo Agent pid 2226;

So, maybe it means that polkit isn't capable of handling ECDSA keys, and it
makes sense because when using seahorse to show the key properties, my ECDSA
key is recognized as a 320 bit DSA key (see attachment).

Same problem here. Looks like gnome-keyring can't use ECDSA keys!

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-keyring (Ubuntu):
status: New → Confirmed
Dave Neary (dneary) wrote :

Does anyone have a workaround? Perhaps a way to get the PID of an existing agent and connect to it when launching a shell? This is really annoying.

Dave.

Chris Danis (cdanis) wrote :

Looks like this is a known issue in gnome-keyring:

https://bugzilla.gnome.org/show_bug.cgi?id=641082

Changed in gnome-keyring:
importance: Unknown → Wishlist
status: Unknown → Confirmed
Andreas Schultz (aschultz) wrote :

ssh-add with ECDSA keys used to work in Xubuntu 12.04 for me, but 12.10 broken it.

It seems that before the ssh keyring was NOT managed by gnome keyring, but it is now.

Tv (tv42) wrote :

Tested on 13.04, still buggy. Manually running SSH_AUTH_SOCK=/tmp/ssh-phxl1McWvuSj/agent.20832 skips gnome-keyring for ssh-agent actions, and makes ecdsa work again -- but naturally that workaround is hard to do, as the random parts keep changing.

Enrique (enrique-garcia) wrote :

 I am having the same problem when logged in a Ubuntu 13.04 server. Therefore no gnome-keyring is running.

Didier Conchaudron (dcn) wrote :

Same problem here. Tested on regular 12.04 with 521 bits long ECDSA:

$ ssh-add
Enter passphrase for /home/user/.ssh/id_ecdsa:
Error reading response length from authentication socket.
Could not add identity: /home/user/.ssh/id_ecdsa

Claudio trick to export ssh-agent variables worked:

$ ssh-add
Enter passphrase for /home/user/.ssh/id_ecdsa:
Identity added: /home/user/.ssh/id_ecdsa (/home/user/.ssh/id_ecdsa)

Changed in gnome-keyring (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Changed in gnome-keyring (Debian):
status: Unknown → New
Changed in gnome-keyring (Debian):
status: New → Confirmed
Isaac (diptongo) wrote :

You can automatically bypass gnome-keyring with the following shell snippet:

export SSH_AGENT_PID=$(pgrep -ou $USER ssh-agent)
export SSH_AUTH_SOCK="$(find -L /tmp -type s -user $USER -name 'agent.*' 2>/dev/null | head -1)"

If you know where to stick it, at session startup, then it may serve as a workaround. Or you can place it in a script just wrapping ssh-add. I'm not sure if the gnome-keyring socket would still work for SSH once the key has been loaded.

Ross Younger (crazyscot) wrote :

ssh-add with ECDSA keys in Ubuntu 14.04 used to work for me, but now that #1271591 has been fixed (gnome-keyring version 3.10.1-1ubuntu4.1) they have broken.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/771272

tags: added: iso-testing
Ivan Voras (ivoras) wrote :

Bump.
Same thing, still not fixed 5 years later.

summary: - ssh-add does not handle ECDSA keys until ssh-agent exports are manually
- launched
+ gnome-keyring doesn't support ecdsa or ed25519 keys
Olleg Samoylov (olleg) wrote :

Here some workarounds:
https://wiki.gnome.org/Projects/GnomeKeyring/Ssh
https://wiki.archlinux.org/index.php/GNOME_Keyring
Perhaps they must be implemented in Ubuntu by default.

Olleg Samoylov (olleg) wrote :

I used
ln -sf /dev/null /etc/xdg/autostart/gnome-keyring-ssh.desktop
worked fine for me (ssh-agent automaticaly launches with d-bus). But you need a root access to do so.

Evgeny Markov (evgenymarkov) wrote :

Almost six years have passed, but bug still not closed.

Sven Neuhaus (sven0) wrote :

This bug annoys me every day. I couldn't believe it when I upgraded from Ubuntu 14.04 to 16.04 and this issue was still present.

Steven Danneman (sdann) wrote :

I'm running 16.04 and attempting to use the builtin Backup program which is a wrapper around deja-dup. I'm trying to target an SSH server for backups, as it will use rsync block comparisons and be the most efficient. However, the SSH server has disabled RSA public key authentication and only supports ecdsa and ed25519.

Backup is using gnome-keyring by default, so it refuses to connect to SSH. From /var/log/auth.log:

May 23 15:10:42 hollywood gnome-keyring-daemon[1599]: Unsupported or unknown SSH key algorithm: ssh-ed25519

Thus, this bug is making other builtin tools less useful as well.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.