gnome-keyring-daemon returns Agent admitted failure to sign using the key.

Bug #328127 reported by Marc Deslauriers on 2009-02-11
This bug affects 22 people
Affects Status Importance Assigned to Milestone
GNOME Keyring
Fix Released
gnome-keyring (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gnome-keyring

Since upgrading to Jaunty, gnome-keyring-daemon doesn't let me authenticate to other hosts using my ssh rsa key anymore.

mdeslaur@mdlinux:~$ ssh mdeslaur@
Agent admitted failure to sign using the key.
Permission denied (publickey).

If I unset SSH_AUTH_SOCK, I can login fine using my rsa key.

gnome-keyring 2.25.90-0ubuntu2 (and 2.26.1-0ubuntu1 as well)

Marc Deslauriers (mdeslaur) wrote :

Downgrading to solves this for me.

Sebastien Bacher (seb128) wrote :

thank you for your bug report, the agent is working fine for me, could you open the bug on since you get the issue?

Changed in gnome-keyring:
assignee: nobody → desktop-bugs
importance: Undecided → Low
Anders Kaseorg (andersk) on 2009-02-11
Changed in gnome-keyring:
status: New → Confirmed
Sebastien Bacher (seb128) wrote :
Changed in gnome-keyring:
status: Confirmed → Triaged
Dustin Kirkland  (kirkland) wrote :

See also Bug #328445, which looks like a dupe.


Confirmed on Jaunty amd64 after upgrading to 2.25.90, post-install.

There seem to be an awful lot of reports, going back to Hardy. This has bitten or is going to bite quite a lot of people, since seahorse is effectively a required core component of Ubuntu (ex. Server?).

Miia Sample (myrtti) wrote :

I'm on Xubuntu Intrepid amd64 with gnome-keyring: Installed: 2.24.1-0ubuntu1 and I've got similar problems.

Chris Cheney (ccheney) wrote :

I'm also seeing this issue on Jaunty amd64, it is keeping me from being able to do svn update from, lol.

David Orman (ormandj) wrote :

Same issue on Jaunty amd64. gnome-keyring 2.25.90-0ubuntu2:

ormandj@ormandj-laptop:~$ ssh neutron -v
OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to neutron [] port 22.
debug1: Connection established.
debug1: identity file /home/ormandj/.ssh/identity type -1
debug1: identity file /home/ormandj/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/ormandj/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'neutron' is known and matches the RSA host key.
debug1: Found key in /home/ormandj/.ssh/known_hosts:5
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more information

debug1: Next authentication method: publickey
debug1: Offering public key: /home/ormandj/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
Agent admitted failure to sign using the key.
debug1: Trying private key: /home/ormandj/.ssh/identity
debug1: Trying private key: /home/ormandj/.ssh/id_dsa
debug1: Next authentication method: password

lithorus (lithorus) wrote :

What is even more weird is that if you generate a new private/public key with ssh-keygen it'll work (after it's copied to the host again) until next reboot.

lithorus (lithorus) wrote :

Seems gnome-keyring 2.25.91-0ubuntu1 fixes this. Can anyone confirm?

Anders Kaseorg (andersk) wrote :

Works for me too now with 2.25.91-0ubuntu1. If anyone still sees this problem after installing this update, feel free to reopen the bug.

Changed in gnome-keyring:
status: Triaged → Fix Released
rupa (rupa) wrote :

works here as well.

Marc Deslauriers (mdeslaur) wrote :

works for me too. Closing bug.

Anand Kumria (wildfire) wrote :

Does not work for me.

Please re-open.

anand@saltatrix:~$ dpkg -l | grep gnome-keyring
ii gnome-keyring 2.25.91-0ubuntu1 GNOME keyring services (daemon and tools)
ii libgnome-keyring0 2.25.91-0ubuntu1 GNOME keyring services library
ii libgnome-keyring1.0-cil 1.0.0~svn.r87622-1 CLI library to access the GNOME Keyring daem
ii libpam-gnome-keyring 2.25.91-0ubuntu1 PAM module to unlock the GNOME keyring upon
anand@saltatrix:~$ ssh-add -l
2048 1b:57:81:8d:62:93:f5:dc:39:08:74:02:63:12:f6:00 anand@saltatrix (RSA)
anand@saltatrix:~$ uname -a
Linux saltatrix 2.6.28-8-generic #24-Ubuntu SMP Wed Feb 18 20:36:18 UTC 2009 x86_64 GNU/Linux
anand@saltatrix:~$ ssh W.X.Y.Z
Agent admitted failure to sign using the key.
Permission denied (publickey,keyboard-interactive).

I get a pop-up box asking for the password but, as you can see, the agent already has the key.

On i386 it works OK.

anand@eve[~]% dpkg -l | grep gnome-keyring
ii gnome-keyring 2.25.91-0ubuntu1 GNOME keyring services (daemon and tools)
ii gnome-keyring-manager 2.20.0-1 keyring management program for the GNOME desktop
ii libgnome-keyring-dev 2.25.91-0ubuntu1 Development files for GNOME keyring service
ii libgnome-keyring0 2.25.91-0ubuntu1 GNOME keyring services library
pi libgnome-keyring1.0-cil 1.0.0~svn.r87622-1 CLI library to access the GNOME Keyring daemon
ii libpam-gnome-keyring 2.25.91-0ubuntu1 PAM module to unlock the GNOME keyring upon login
anand@eve[~]% ssh-add -l
1024 3c:76:cb:dc:4f:02:fd:2a:70:c8:db:0a:06:cc:78:96 anand@eve (RSA)
anand@eve[~]% uname -a
Linux eve 2.6.28-7-generic #20-Ubuntu SMP Mon Feb 9 15:43:21 UTC 2009 i686 GNU/Linux
anand@eve[~]% ssh W.X.Y.Z
Last login: Mon Feb 16 11:03:31 2009 from
anand@fwb1:~> exit
Connection to W.X.Y.Z closed.

Changed in gnome-keyring:
status: Fix Released → In Progress
Andreas Moog (ampelbein) wrote :

I forwarded your comment to the developers. Please don't use the status "In Progress" unless you are working on fixing the issue. You can learn more about bugs status at Thanks for your help.

Changed in gnome-keyring:
status: In Progress → Triaged
Andreas Moog (ampelbein) wrote :

Comment from Upstream:

I'm really interested in more specific failures, or an SSH key that'll help me
solve the problem:

 * If gnome-keyring-daemon is crashing, I need a backtrace.
 * If there's lines in /var/log/auth.log or ~/.xsession-errors I need those.
 * Or I need a key that I can use to duplicate the problem.

Changed in gnome-keyring:
status: Triaged → Incomplete
Matt Zimmerman (mdz) wrote :

Works fine here, anyone still affected should file a new bug.

Sebastien Bacher (seb128) wrote :

the bug described there has been fixed please open a new one if you have a similar issue

Changed in gnome-keyring:
status: Incomplete → Fix Released
Changed in gnome-keyring:
status: Unknown → Incomplete
CPKS (c-1) wrote :

I upgraded to Jaunty last night, and now I have this problem (2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux).

Unlike the previous commenter, I was getting no request for my password to unlock the keyring.

Having read through the comments on bug #328445, I found that a temporary workaround - which will work for all processes, is to ascertain the value of SSH_AUTH_SOCK. On my system it has the following value:


This file doesn't exist. However, there is another directory in /tmp called ssh-gPkVBp3144 and this contains just the file agent.3144. If I execute

$ ln /tmp/ssh-gPkVBp3144/agent.3144 /tmp/keyring-nWDqUT/socket.ssh

Then SSH authenticates fine.

David Thorne (cferthorney) wrote :

I too am having this issue having upgraded from Intrepid.

The SSH_AUTH_SOCK trick seems to work, as does generating a new key (Something I am loathed to do I have a number of current keys which are used in a number of places and I don't fancy regenerating them all) I am using the following version of Gnome-keyring:
sudo dpkg -l | grep gnome-keyring
ii gnome-keyring 2.26.1-0ubuntu1 GNOME keyring services (daemon and tools)
ii libgnome-keyring0 2.26.1-0ubuntu1 GNOME keyring services library
ii libgnome-keyring1.0-cil 1.0.0~svn.r87622-2 CLI library to access the GNOME Keyring daem
ii libpam-gnome-keyring 2.26.1-0ubuntu1 PAM module to unlock the GNOME keyring upon

and Seahorse:
sudo dpkg -l | grep seahorse
ii seahorse 2.26.1-0ubuntu1 A Gnome front end for GnuPG
ii seahorse-plugins 2.26.1-0ubuntu1 seahorse plugins and utilities for encryptio

Does the downgrade cause any issues with other packages (GnuPG etc)?

Johnathon (outdooricon) wrote :

If this was fixed at one time, it has now regressed because I am using all latest Jaunty packages, and I can reproduce the error and also can use the setting of SSH_AUTH_SOCK=0 to temporarily bypass it...

Changed in gnome-keyring (Ubuntu):
status: Fix Released → Confirmed
Sebastien Bacher (seb128) wrote :

somebody having the issue needs to reply to upstream comments

Changed in gnome-keyring (Ubuntu):
status: Confirmed → Incomplete
MountainX (dave-mountain) wrote :

I have the problem on a brand new Jaunty AMD64 install. As Johnathon wrote, I can reproduce the error and also can use the setting of SSH_AUTH_SOCK=0 to temporarily bypass it.

To reproduce, I open a terminal and type "ssh myuser@myserver".
I do this command many times per day to different servers (all passwordless) and I never had this issue until I installed Jaunty today.

Responses (the best I can do):
 * If gnome-keyring-daemon is crashing, I need a backtrace.
I'm running ssh in a terminal.

 * If there's lines in /var/log/auth.log or ~/.xsession-errors I need those.
I do not see any relevant messages in these files.

 * Or I need a key that I can use to duplicate the problem.
I will make a new key (that I can attach) and try to reproduce the steps after I unset SSH_AUTH_SOCK=0 (once I figure out how to do that...)

I am experiencing the same issue by generating the private rsa key from seahorse and from inside the cli as well.

Seahorse and ssh-copy-id both copy the key to the remote user, but every time I try to connect, the error message gets shown.

No errors get logged inside my home/.xsession-errors, nor in /var/log/auth.log

Here follow my two keys:


ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArOElXA9OgEITnk43htSTVA4MKCq3fgx+IbciDhy9RIdYP62HqWV6+X3UOQEP0QTMP+mDvs2p88WrJ+ukNCAA41qxbJb8j199GsGp3o8InjOh6yCpGmwg5DKynRrRv2ZIv4zlPx+ZxZx9WAskT50Tu7Op2QW3MKLCLNdB3XGevOjUhniMwkEI4GxA/BI9dOiM097GjmzAffB103NsIxknfvgNaZ5oI5Z6PHej/QYDxn2MAQ3i4IEST791YssFIq6bH4oWiwMvqIySPBM2xAf8HOvxphZ4UtkiV0WrFXoNJvumPnUAQNd+pvZ/W+iSW+38/0jeD/uVPmdlg4GPysUNNw== mylocaluser@client to myremoteuser@server

client side apps:

libryptui0 2.26.1-0ubuntu1
openssh-blacklist 0.4.1
openssh-blacklist-extra 0.4.1
openssh-client 1:5.1p1-5ubuntu1
openssh-server 1:5.1p1-5ubuntu1
seahorse 2.26.1-0ubuntu1
seahorse-plugins 2.26.1-0ubuntu1
ssh-askpass-gnome 1:5.1p1-5ubuntu1

server side apps:

libryptui0 2.26.1-0ubuntu1
libgnome-keyring0 2.26.1-0ubuntu1
libpam-gnome-keyring 2.26.1-0ubuntu1
openssh-client 1:5.1p1-5ubuntu1
openssh-server 1:5.1p1-5ubuntu1
seahorse 2.26.1-0ubuntu1
seahorse-plugins 2.26.1-0ubuntu1
ssh 1:5.1p1-5ubuntu1
ssh-askpass-gnome 1:5.1p1-5ubuntu1

description: updated

Just submitted my previous post (with private/public keys) to

BTW: isn't it bad/confusing to double post? Which site should be the preferred one?

MountainX (dave-mountain) wrote :

After I rebooted, I have never seen the problem again. I'm not sure why it was transient in my case. And I didn't do anything (afaik) to resolve it, but it is gone.

MountainX (dave-mountain) wrote :

Oh, I should have checked this before posting my last comment.
myuser@myserver:~$ echo $SSH_AUTH_SOCK


Maybe that's why I'm not having a problem any more?
(for context, see where I mention that setting of SSH_AUTH_SOCK=0 eliminates the error for me)

Jon Dowland (jond) wrote :

I'd say once the bug was confirmed upstream it would make sense to perform further work there.

I'm using jaunty i386 and I started to experience the same issue.

Everything was ok then I generated a keypair using ssh-keygen with a non-empty passphrase. I copied it to my target machine's .ssh/authorized_keys file and ssh command was able to log in (the passphrase was asked in a window dialog).

After sometime I decided not to use a passphrase anymore. So I used ssh-keygen with empty passphrase. This new key pair and all the subsequent ones I created (with empty passphare or not) did not work, reporting `Agent admitted failure to sign using the key', without even asking for a passphrase.

After reboot, I didn't see the problem.

Repeating the process (setting up new key pairs), I happens again.

Then I found out a way to fix it without rebooting:

1. remove the key pair files from ~/.ssh directory.
2. ssh the remote machine (this is step is needed). Don't need to login, just wait for the password prompt.
3. generate a new key pair.

After setting the public key in the remote site, the problem goes away.

It seams that seahorse does not like the key pair being modified externaly.

I am able to provide any more information as needed.

MountainX (dave-mountain) wrote :

The steps Pedro Pedruzzi describes ( are identical to the steps that originally produced the bug for me. (However, I did not go as far as he did to reproduce it again after rebooting.)

Setting status to new, since I believe anyone is able reproduce this issue based on my last message.
Waiting for confirmation.

Changed in gnome-keyring (Ubuntu):
status: Incomplete → New
rtjmay (rtjmay) wrote :

I can confirm that the steps provided by Pedro do work on Jaunty AMD64 when the new key-pair must be created and setup in Seahorse.

Architecture: i386
DistroRelease: Ubuntu 9.04
Package: gnome-keyring 2.26.1-0ubuntu1
PackageArchitecture: i386
 PATH=(custom, user)
Uname: Linux 2.6.28-11-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Hendy Irawan (ceefour) wrote :
Vladimir Hidalgo (vlad88sv) wrote :

I think something like this is more important than "low".

This was really driving me crazy for a day, I don't restart too often my PC (each two days), so thankfully I got here searching for "Agent admitted failure to sign using the key."

Problem for me is I can't restart till tomorrow, and I can't SSH the target machine directly (

I tried restarting everything SSH-related but seems of not help.

I'll try Pedro's solution for now. Anyway, I don't think this should be taken as a low priority bug.

Vladimir Hidalgo (vlad88sv) wrote :

Sorry to double post, but I tried this (using passphrase) and everything went as expected (not need to reboot). So I think that what he said: "It seams that seahorse does not like the key pair being modified externaly." seems not true, because then passphrase would not matter.

So basically this bug in short is: "keys produced by ssh-keygen without passphrase are not valid until system's reboot".

The bug was confirmed by at least 3 users.

Changed in gnome-keyring (Ubuntu):
status: New → Confirmed
CPKS (c-1) wrote :

Still apparent in Karmic alpha 3, 2.6.31-5-generic #24-Ubuntu SMP Sat Aug 1 12:47:58 UTC 2009 x86_64

Confirm still apparent in Kamic alpha 3, 2.6.31-6-generic #25-Ubuntu SMP Fri Aug 14 16:25:04 UTC 2009 i686

george@georgenotebook:~$ ssh mythtvbox date
Agent admitted failure to sign using the key.
george@mythtvbox's password:


george@georgenotebook:~$ SSH_AUTH_SOCK=0 ssh mythtvbox date
Tue Aug 18 01:11:22 CDT 2009

I just did a fresh install of Karmic alpha 4 and did all updates. The bug is completely gone.

I don't know if it was fixed from this bug report, but BIG THANKS to those that fixed it.

Sebastien Bacher (seb128) wrote :

could you try if that's still an issue in the current karmic version?§

Sebastien, that is as current as Karmic gets. No problems. Bug is gone.

Sorry if I miss understood your question.

Sebastien Bacher (seb128) wrote :

Thanks for the update that was the question indeed, it would be nice if other people on this bug could confirm that the issue is fixed for them too

With a latest patched karmic, if I copy a dsa key in as .ssh/identity, then try to ssh to another host, then I get a gui request box asking for they passphrase, and I then get connected to the host. So it seems like it works for me.

Sebastien Bacher (seb128) wrote :

closing since that works now

Changed in gnome-keyring (Ubuntu):
status: Confirmed → Fix Released
CPKS (c-1) wrote :

Using Karmic with latest updates, 2.6.31-9-generic #29-Ubuntu SMP Sun Aug 30 17:39:26 UTC 2009 x86_64, I still get the "Agent admitted" message, but am then asked for the appropriate passphrase and then ssh connects appropriately. Unsetting SSH_AUTH_SOCK suppresses the "Agent admitted" message.

I have 5 computers running Karmic (2-x86 and 3-x86_64). I can't reproduce this issue. To me it seems to be gone.
Did you upgrade to Karmic or do a fresh install, CPKS?

CPKS (c-1) wrote :

I attempted to upgrade (back when it was alpha 2), but the process bombed out so I installed Karmic over the top of a copy of a happy Jaunty install. The system is stable, upgrading OK, and I'm keeping it up to the minute with updates.

Currently, running 2.6.31-10-generic #32-Ubuntu SMP Thu Sep 10 23:29:56 UTC 2009 x86_64, when I run ssh I'm back to seeing exactly the behaviour I had under Jaunty, i.e. the installed ssh key is not being used at all: I'm not being asked for its passphrase. I would be glad to provide any further information to help locate this problem.

bingalls (bruce-ingalls) wrote :

I upgraded to Karmic 9.10. Subversion v1.6 now fails, with:
  svn up --username myname

  Password for 'login' GNOME keyring:
  svn: OPTIONS of 'http://svn-repository': authorization failed: Could not authenticate to server: rejected Basic challenge (http://svn-repository)

Note that I am using basic auth, and that my username is not 'login' I am connecting to a v1.4 svn server. Svn v1.6 worked on Jaunty. I compiled svn v1.4 from source, and that works on Karmic; it does not prompt me for the Gnome Keyring.

Scott Bronson (bronson) wrote :

I started with a stock Karmic Gnome desktop running (other than a bunch of packages like openssh-server, openssl, etc installed). Ran ssh-keygen -b 4096 and put a passphrase on the key. now:

- $ git clone git://etc -- fails with "github Agent admitted failure to sign using the key."
- $ SSH_AUTH_SOCK=0 git clone git://etc -- works just fine!

So, I'm pretty sure there's still a bug here!

CPKS (c-1) wrote :

Seems to be fixed now in Lucid, both 32-bit and 64-bit.

Vasile Rotaru (vrotaru-md) wrote :

Well I've run into the same problem no longer than yesterday and as a matter of fact some minutes ago

ssh <email address hidden> .. fails with:

debug1: Server accepts key: pkalg ssh-rsa blen 277
Agent admitted failure to sign using the key.

SSH_AUTH_SOCK=0 ssh -v <email address hidden> .. succeeds with:

Hi ..! You've successfully authenticated,

I have the same issue on a new install of Lucid i386 on a Lenovo T61. The ssh-add fix does not work, but unsetting SSH_AUTH_SOCK does.

Gareth Williams (gareththered) wrote :

I also have this issue, but only since I rebuilt the ssh server (Ubuntu Server 10.04 LTS) and created new keys. My client (Lucid) hasn't changed other than routine updates and I don't recall any ssh ones there.
The SSH_AUTH_SOCK fix works.

Gareth Williams (gareththered) wrote :

Also noticed that the 'ssh-add' fix worked for me. Should have tried it before my previous post!

Every time I install a later version of Ubuntu, and mount my previous versions /home partition during installation, I get prompted for keyring authentication for any encrypted wireless networks I attempt to connect to.

Here's how I have to solve this problem each time:

Changed in gnome-keyring:
importance: Unknown → Medium
status: Incomplete → Fix Released
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.