gnome-keyring doesn't support ecdsa or ed25519 keys

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!

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

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.

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

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

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.

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.

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

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)

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.

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.

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

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

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.

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.

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

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.

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.

Used the workaround in #12, but it is still a major annoyance that gnome-keyring-daemon does not handle this.

Why is this marked as "Fix Released"?

ED25519 keys don't work. https://bugzilla.gnome.org/show_bug.cgi?id=723274

@Eero, ED25519 is supposedly working in Seahorse 3.20 but I still can't get it to work in Ubuntu 18.04