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

Downgrading to 2.25.4.1-0ubuntu1 solves this for me.

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

bug open on http://bugzilla.gnome.org/show_bug.cgi?id=571422 now

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

:-Dustin

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?).

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

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

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 [192.168.1.100] 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_REQUEST sent
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

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.

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

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.

works here as well.

works for me too. Closing bug.

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 91.106.31.73
anand@fwb1:~> exit
logout
Connection to W.X.Y.Z closed.
anand@eve[~]%

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 https://wiki.ubuntu.com/Bugs/Status. Thanks for your help.

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.

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

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

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:

$ echo $SSH_AUTH_SOCK
/tmp/keyring-nWDqUT/socket.ssh

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.

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)?

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...

somebody having the issue needs to reply to upstream comments

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:

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEArOElXA9OgEITnk43htSTVA4MKCq3fgx+IbciDhy9RIdYP62H
qWV6+X3UOQEP0QTMP+mDvs2p88WrJ+ukNCAA41qxbJb8j199GsGp3o8InjOh6yCp
Gmwg5DKynRrRv2ZIv4zlPx+ZxZx9WAskT50Tu7Op2QW3MKLCLNdB3XGevOjUhniM
wkEI4GxA/BI9dOiM097GjmzAffB103NsIxknfvgNaZ5oI5Z6PHej/QYDxn2MAQ3i
4IEST791YssFIq6bH4oWiwMvqIySPBM2xAf8HOvxphZ4UtkiV0WrFXoNJvumPnUA
QNd+pvZ/W+iSW+38/0jeD/uVPmdlg4GPysUNNwIBIwKCAQEAmR8vt/BM2AACv2nZ
aMro5AxxKuQBm4doZwFKDH/a1kv9tL5E9R9eSrFG8KkrRBoxP+wVml5jVEFdFLrE
ozJJ7fE+D7juUxoPuJzm6bHjD8dU5jLe64RXpYv9SVJEv3faCL6fKUff+CuE9jXB
E1CccwzYQ+B9rrwLEcX4gk6xKvimM90r6wP4kEiZ9PIpj3bee3epDCQfgIYxDTpV
+mbAg0XtIcjK9PUQYD6XQx7oHzxROAdy3F9xrhN5DhJx1Kj5xadyR9eIy5nVZQf1
RXCScG51Qz/l76+7Ma/oh144liaDkPYu0Br/HmiyOwE+IOELbO/TQc3nFMzUz1Y9
c/qBIwKBgQDdD4VtIS8nku1Harc59Ay0E+NdfJQb5mghscJLkiqW7XLpiWaAEulz
FAsGSjiw/zjfKHLre35u8slE+q1i61/sQcoaoMi4Bb8sd5AYPQ3TFp1TbbG+Kw0V
gOv2LglW/mEf3X7lurpJ5K7LNKH4piklNWjT9zeRNB863Abe+LMEIwKBgQDINCK0
POQbPz2FjVHc1p/2VZ2ZsY7TmxHar6kSEx+3Nx1quhMj89poSCXy6yZMtIS0PoIK
W6+nJM+v/WOl05gpgrib67J6F8TgMWmeQNXmyW7PgRyVhInF4FEJNdTI2erplAEv
/kDKZiQUNzzwd9+I0wLRQhVZ+w5TKL579EnJ3QKBgQCRRLbEDn4SsQJTgKRKp7CT
mApwolKzP6OD2zaJbq5F7H62uWCdTkGjZPFNRreKQVFCMIYIdbl8G+NZNwQ5sJ4e
6WeN119UW4xByumphzT4bfJbZVeLmKIys85CsInLc/auij1yZMOPpOfknu4YbTD7
MbnqYKDbwyp3It/xnB3eJQKBgQCDj/mMYodFGu3qDGj+1i6akAh68QYWBtE378bf
/fBFMtjRGzEmQSkf9OW846t0PByw9eBtNO/Fm9jv/kjMDrRzDMJ1FzrFQtHVJ8kQ
OTwbUSuPrJ3BVxi1O6L3bISD/OrUAiyqgoJZHoy809eWtSx+fAkqbUE7IVKOaztY
xRqL9wKBgEbILKNU+y5S2FBVeuEe58zXiCt00/DQXVIKc/W2V74pFrXwHFAe6n5e
2pvSjUCw+ybJHs433mz1a98WaeTKl42kj3J4QilCa9TZA59DJAgXN5x5ExAaZScC
p4h8yY4ULixqe1h++hbFY924i2RjP9+DFdb9S6JXt04GrSV8DRwf
-----END RSA PRIVATE KEY-----

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

Just submitted my previous post (with private/public keys) to http://bugzilla.gnome.org/show_bug.cgi?id=571422

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

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.

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

myuser@myserver:~$

Maybe that's why I'm not having a problem any more?
(for context, see https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/328127/comments/23 where I mention that setting of SSH_AUTH_SOCK=0 eliminates the error for me)

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.

The steps Pedro Pedruzzi describes (https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/328127/comments/29) 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.

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
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
Uname: Linux 2.6.28-11-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

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 (GitHub.com)

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.

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/328127/comments/29

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.

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:

WITH SSH_AUTH_SOCK=0 WORKAROUND:

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.

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.

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.

closing since that works now

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?

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.

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.

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!

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

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.

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.

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:
http://www.howtoadvice.com/KeyringPasswords