ssh Agent admitted failure to sign using the key on big endian machines

[sam tygier]

on hardy (preserved home folder from feisty) i get the following when i try to ssh

Agent admitted failure to sign using the key.
Permission denied (publickey).

or with verbose on

sam@titania:~$ ssh -v oberon
OpenSSH_4.7p1 Debian-4ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/sam/.ssh/config
debug1: Applying options for oberon
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to ###### [######] port ##.
debug1: Connection established.
debug1: identity file /home/sam/.ssh/identity type -1
debug1: identity file /home/sam/.ssh/id_rsa type 1
debug1: identity file /home/sam/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.6p1 Debian-5ubuntu0.1
debug1: match: OpenSSH_4.6p1 Debian-5ubuntu0.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-4ubuntu1
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: using hostkeyalias: oberon
debug1: Host 'oberon' is known and matches the RSA host key.
debug1: Found key in /home/sam/.ssh/known_hosts:1
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
debug1: Next authentication method: publickey
debug1: Offering public key: /home/sam/.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/sam/.ssh/identity
debug1: Trying private key: /home/sam/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

I tried generating a new key. this worked for a few logons, but then i get back to this error.

I think it is to do with the local key agent. i found that
 SSH_AUTH_SOCK=0 ssh oberon
works fine.

[Nicolas Valcarcel (nvalcarcel)]

Can you please post the your config files (/home/sam/.ssh/config and /etc/ssh/ssh_config) aswell as you sshd_config file from the server you are trying to connect to.

[Colin Watson (cjwatson)]

Is there a process called seahorse running?

[sam tygier (samtygier)]

sam@titania:~$ cat .ssh/config
Host flute
HostName ####
Port 23
HostKeyAlias flute

Host oberon
HostName ###
Port 22
HostKeyAlias oberon

Host naught
HostName ###
Port 22
HostKeyAlias naught

sam@titania:~$ cat /etc/ssh/ssh_config

# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
# ForwardAgent no
# ForwardX11 no
# ForwardX11Trusted yes
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# MACs hmac-md5,hmac-sha1,<email address hidden>,hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

sam@oberon:~$ cat /etc/ssh/sshd_config
# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no ...

[Marcus Asshauer (mcas)]

I can confirm this Bug. Setting SSH_AUTH_SOCK=0 works for me too.

[Berend De Schouwer (berend-de-schouwer)]

If I use ssh-agent instead of seahorse, it works. Seahorse never even asks for a passphrase for the key. Hence, I think it's a seahorse bug.

You can use ssh-agent instead by editing /etc/X11/Xsession.d/60seahorse and adding unset SSH_AUTH_SOCK

[fish (discordianfish)]

Same problem here, unsetting SSH_AUTH_SOCK works too.

[Nelson Pavlosky (nelson-freeculture)]

I still experience this bug on Hardy Heron PPC. Saying e.g. "SSH_AUTH_SOCK=0 ssh oberon" works fine for me, but I can't figure out how to edit that X11 config file. Can someone fix this so we can stop using silly workarounds?

[Allison Karlitskaya (desrt)]

I have this problem on my computer at work but on none of my other computers.

Two things that are unique about my work computer compared to the others

1) It has been upgraded many times (since breezy, I think)

2) It is non-Intel (PowerPC).

Is everyone else here falling under one or both of these categories? Perhaps it will help find the cause....

[John Steele Scott (toojays)]

I'm also getting this on Fedora 9 PPC. I don't think seahorse is installed. Besides the SSH_AUTH_SOCK workaround, another workaround is to run "ssh-add" once after logging in.

[feiy (eshangrao)]

Confirm in Ubuntu intrepid

set SSH_AUTH_SOCK=0 can fixed it!

[Sarah Kowalik (hobbsee-deactivatedaccount)]

also getting this here.

I'm having success with both ssh-add and the SSH_AUTH_SOCK workaround

[Martin Maney (maney)]

Just banged nose-on into this on a new Hardy install (but using the old /home); it was up to date against the official repositories a few hours ago. None of the above fixes really worked for me, but (so far - simple remote logins from the xterm with the agent providing authentication) what's working for me is replacing /usr/lib/gnome-keyring/gnome-keyring-ask with a symlink to /bin/false. I no longer get the stupid and useless popup dialog when I run, eg., ssh-add -l, or ssh <options> {user@}hostname - it just works, as it had done for many years in every distro before Hardy.

[Martin Pitt (pitti)]

Sam, as the original bug reporter, can you confirm that you are also on a big endian machine like PowerPC?

[Brian Murray (brian-murray)]

I am experiencing this bug on an amd64 machine.

[Brian Murray (brian-murray)]

My ssh error message looks quite different than the original reporter's now.

[sam tygier (samtygier)]

i was on powerpc (big endian).

[zcrar70 (eliemedeiros)]

I am also getting this error on an AMD64 machine. The error message I get is still "Agent admitted failure to sign using the key", although the output of ssh -v <hostname> is a little different - here it is up to when it prompts me to use a password to login:

OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/nick/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to nick-curry.com [74.86.89.209] port 22.
debug1: Connection established.
debug1: identity file /home/nick/.ssh/identity type -1
debug1: identity file /home/nick/.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/nick/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
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 'nick-curry.com' is known and matches the RSA host key.
debug1: Found key in /home/nick/.ssh/known_hosts:1
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/nick/.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/nick/.ssh/identity
debug1: Trying private key: /home/nick/.ssh/id_dsa
debug1: Next authentication method: password
<user>@<hostname>'s password:

[zcrar70 (eliemedeiros)]

I forgot to mention, I'm using Intrepid and I wasn't getting this error on Hardy (though I may not have had the latest version of seahorse or gnome-keyring, as I had update-manager disabled for a while).

[Unca Xitron (benny-egovmt)]

I'm running Intrepid, and like zcrar70 did not have the problem under Hardy.

I've found if I close the first dialog box twice, and the Ctl-C the command-line, the next time I try it it works fine. Weird.

[pat.pannuto (ppannuto)]

I too am experiencing the same bug. Running 8.10, 64-bit on a Core2Duo.

This bug first appeared when I changed the passphrase for my key, everything was working fine before that. The workarounds above worked fine for me, and my ssh -v output is the same as well.

[pat.pannuto (ppannuto)]

Interestingly, restarting X causes this bug to go away. For those experiencing this bug, did it "just show up one day", or did you do something out of the ordinary (eg, change keys, change your passphrase, in any way modify your ~/.ssh directory while running, perhaps deny the keyring once - anything out of the ordinary)?

[zcrar70 (eliemedeiros)]

In my case, it happened after upgrading to Intrepid - no passphrase or key changes or anything else out of the ordinary that I remember. I am still getting the error.

[Unca Xitron (benny-egovmt)]

Like zcrar70, I'm pretty sure mine started when I upgraded to Intrepid. No passphrase or key changes. Nothing else out of the ordinary that I recall. No denying keyring.

[Jeffrey Baker (jwbaker)]

This started happening to me "out of the blue" on Jaunty amd64.

[adinsx (adinsx3)]

I just began having this problem in Jaunty amd64 as well. It was working fine as of last night, but today I run into this. I should note that I can use sftp via gnome/gvfs/(whatever the exact program that handles sftp in gnome is) with the exact same key to the same server.

Also, if I open seahorse -> select my private key -> Configure key for secure shell -> enter in required information, seahorse gives me the same error message as the terminal ssh client.

The SSH_AUTH_SOCK=0 workaround fixed my problem.

[adinsx (adinsx3)]

I ended up doing this:
gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false

Fixed my problem once I logged out/in.

[Dustin Kirkland  (kirkland)]

Marking confirmed, I'm experiencing this problem now on Jaunty as well.

:-Dustin

[Dustin Kirkland  (kirkland)]

Interestingly, if I regenerate my keypair, the new ones work.

I'm using a 4096 bit rsa key. My system is an up-to-date Jaunty amd64 install.

Also, the new, working key appears to be 4 bytes shorter...

$ wc id_rsa orig/id_rsa
  51 57 3239 id_rsa
  51 57 3243 orig/id_rsa

:-Dustin

[Sebastien Bacher (seb128)]

the jaunty issue is likely a different one

[Anand Kumria (wildfire)]

Hi Sebastien,

How we can help diagnose the problem? The issue description is wrong (since earlier commentators indicated that it also failed on amd64).

I have an i386 and amd64 machine and am only expericing this issue on the amd64 one.

Thanks,
Anand

[Dustin Kirkland  (kirkland)]

The new problem being experienced on Jaunty has been split out to Bug #328445.

:-Dustin

[Tim Utschig (tim-magnumsemi)]

Running into this on intrepid. I have two keys loaded into my gnome-keyring agent, one DSA, one RSA. Pubkey auth using the DSA is key is failing with the "Agent admitted failure" message, but RSA succeeds immediately after.

Ran an strace, and noticed that it's writing the following to syslog:

   Feb 12 20:13:12 timlaptop gnome-keyring-daemon[6368]: signing of the data failed: Invalid object

[Unca Xitron (benny-egovmt)]

Decided to try Tim Utschig's approach and lose the DSA key I'm no longer using, with no positive outcome. Interesting observation, though, and one I hadn't considered.

One addition to this that may or may not be unique to my machine. When I first attempt an ssh, the dialog box that pops up reads:
  "Unlock login keyring
   Enter login password to unlock keyring
   Your login keyring was not automatically unlocked when you logged into this computer
   Password"

No matter what I put in there, no joy. But if I close that dialog box using the X in the corner, the next dialog box that pops up reads:
  "Unlock private key
   An application wants access to the private key 'id_rsa', but it is locked.
   Password"

When I then enter the key's password in that 2nd dialogue box, everything works fine. So for me, the problem seems to exist with the first issue, where it's unlocking what it calls my "login keyring". Can anyone help clarify this for me? Is that portion something I can easily disable without disabling the 2nd portion? Or is there a way to set the password for that "login keyring"?

Unca Xitron

[Christian Albrecht (christian-urban-souls)]

I have had the problem on my upgraded from Intrepid Jaunty installation.

It seems to be that gnome-keyring has a problem while reading my private key in dos format (CR/LF). After converting it to unix format it works like a charm.

I've used dos2unix (tofrodos package) to do the job.

[Hendy Irawan (ceefour)]

Architecture: i386
DistroRelease: Ubuntu 9.04
Package: openssh
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

[Cédric Jeanneret deactivated (cjeanneret-c2c-deactivated)]

Hello.

Same problem on a recently reinstalled Jaunty.

Informations :
Architecture : i386
Release : 9.04

Packages version:

dpkg -l | grep seahorse
ii libcryptui0 2.26.1-0ubuntu1
ii seahorse 2.26.1-0ubuntu1
ii seahorse-plugins 2.26.1-0ubuntu1

System is up to date.

One thing though : we kept user's home when we reinstalled his computer. BUT we removed all his preferences :
for dir in .gconf .gconfd .gnome .gnome2 .gnome2_private .local .config
do
  rm -r $HOME/$dir
done

When we do a "ssh-add", it works again.
I tried to do Christian Albrecht fix, but it didn't work on this computer.

[Patrick Walker (phobiac)]

I'm having the same exact problem, and the SSH_AUTH_SOCK=0 fix works. I'd remove all my config files like previously posted, but I don't want to reconfigure everything. I've tried search all of the folders Cédric Jeanneret said were deleted for SSH_AUTH_SOCK and even SSH, but turned up nothing. The search was peformed with grep -riHn 'ssh_auth_sock' /folder/path
Any other suggestions on what to do and or search for?

[Cédric Jeanneret deactivated (cjeanneret-c2c-deactivated)]

Hi again,

Searching some informations on seahorse' ssh-agent, I found this thing:

"""/!\ Note: This only applies to versions of Seahorse prior to 2.22. In 2.22 and later a full SSH agent is included in gnome-keyring and the agent proxy in Seahorse has been retired. """

maybe there are some problems with versions of those programmes in ubuntu?

See source:
http://live.gnome.org/Seahorse/SSHAgent

Regards,

C.

[Austin English (austinenglish)]

Still present in Jaunty. Using SSH_AUTH_SOCK=0 still works around it.

[TheTom (tomgey)]

I also had this problem in karmic while connecting to a launchpad branch with bazaar. After an "ssh-add" it works.

[TheTom (tomgey)]

I also had this problem in Karmic while connecting to a launchpad branch with bazaar. After an "ssh-add" it works.

[James Clemence (jvc26)]

Jaunty issues continue:

SSH_AUTH_SOCK=0 ssh <host> offers a temporary fix, but ssh-add fixes for good - is there any way to make this process automatic - say - I'm using a new key, prompt user to ok the ssh-add (dont do behind the scenes), and all fixed and done?

Il

[Alexander Telenga (telenga)]

Confirm. After an "ssh-add" push to bazaar works.

[Marco Diaz (zethabyte)]

I had the same problem in Ubuntu 9.04

the problem was solved with gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false

[Eric Stein (estein)]

I get this on Gentoo amd64. SSH_AUTH_SOCK=0 workaround works fine. Just weird, I don't recall wanting this "feature" in SSH.... and there doesn't seem to be an option to make it not do this.

[AlainODea (alain-odea)]

This is reproducible when using 'ssh-keygen -t rsa' multiple and saying yes to overwrite the existing ~/.ssh/id_rsa and ~/id_rsa.pub.

I can reproducibly fix it by running 'ssh-add ~/id_rsa'

[AlainODea (alain-odea)]

BTW, I am running Ubuntu 9.10 Karmic Koala and this happens and the "ssh-add" fix works when I attempt to connect to a Gitosis server on the same machine.

[demizer (jeezusjr)]

I ran into this same problem in Karmic. Using 'ssh-add ~/.ssh/id_rsa' on the machine I am trying to connect with fixed the problem.

[sionib (sionib)]

Same problem in karmic. I found this solution : export SSH_AUTH_SOCK=0
It's works fine.

[Jeff Hatfield (nomasteryoda)]

I concur... this is a problem that should have been fixed by now. When I run "export SSH_AUTH_SOCK=0 on the host machine, I have no problem connecting to the target system after placing the key in the authorized_keys2 file (on target).

Note: This must be done for each and every shell opened on the host.

nuts I tell ya.

[Mikko Ohtamaa (mikko-red-innovation)]

Utterly annoying.

As a workaround put line

export SSH_AUTH_SOCK=0

to

/home/YOURUSERNAME/.bashrc file.

Works for terminal sessions only, though.

[Oded Arbel (oded-geek)]

I had this problem today, with Karmic. The problem went away after a logged out and logged back in - I'm not sure what the problem is with older versions, but I think in Karmic the problem is that seahorse does not update with the new key when a new key is created while it is running.

If you try to kill seahorse, you're going to kill your X session because seahorse is running under dbus-launch. Obviously logging out whenever you create a new SSH key is not a good workaround.

[bitinerant (bitinerant)]

This one bit me when I deleted my old ssh keys and generated new ones on Karmic. Both work-arounds worked for me (I tried them individually)--adding the line "export SSH_AUTH_SOCK=0" to ~/.bashrc OR running "ssh-add ~/.ssh/id_rsa". I like the latter better because it doesn't require extra work to distribute to the systems I use.

[Stuardo -StR- Rodríguez (stuardo)]

same here, out of the box lucid. , the ssh-add didn't solve the problem. the SSH_AUTH_SOCK=0 added to the bashrc file works, but it still is a pain

[Tim Utschig (tim-magnumsemi)]

Just my $0.02...

If you use an SSH agent, do yourself a favor and use OpenSSH's
own ssh-agent. I've found
seahorse/gnome-keyring-daemon/whatever very unreliable,
especially when I run dozens of parallel ssh commands (which all
use public key auth via the SSH agent). I give it a chance with
each new Ubuntu release, but each time it has failed me.

I always end up falling back to the following in ~/.bashrc:

  export SSH_AUTH_SOCK="$HOME/.ssh/.authsock"

and the following alias for starting a new agent (once per boot):

  alias ssh-agent-init='bash -c '\''eval "`ssh-agent -s`"; ln
-sf $SSH_AUTH_SOCK $HOME/.ssh/.authsock; echo "Agent authsock
$SSH_AUTH_SOCK"; ssh-add /path/to/mykeys/id_[rd]sa'\'

I hear people also use the "keychain" package to achieve the
same, though I haven't looked at it.

    http://packages.ubuntu.com/lucid/keychain

--
Tim Utschig<email address hidden>
Network / Unix Systems Administrator
Magnum Semiconductor
Desk: 408-934-3754 , Mobile: [phone]

[Portable-Jim (christian-chess-geek)]

Same problem:
iBook G4 (PPC)
Ubuntu 10.04 Lucid Lynx

Order of events:
1. Switched from Debian. Copied home. - Problem appeared
2. Re-created keys and copied key across to authorised keys - Problem persisted
3. Deleted all keys, regenerated and copied key across to authorised keys - Problem persisted.
4. Ran "ssh-add" - Problem went away.

Thanks.

[Ray (bernhard-posselt)]

Got the same problem here, fixed it by running ssh-add after key creation thanks to Portable-Jim

[Pavel Strakhov (strahovp)]

The same problems. After SSH_AUTH_SOCK=0 all works fine.

[poloshiao (poloshiao)]

It was Ok when I installed openSSH on this May as soon as ubuntu 10.04 LTS came out.
It encountered the same problem as described above when I make another new installation this afternoon.
It was resolved after runnig ssh-add ~/.ssh/id_rsa as said on these comments.
I found out another thing not mentioned here.
There was a file called known_hosts in ~/.ssh/ when I installed on this May.
This file known_hosts disappeared when I installed this afternoon, so it failed.
The file known_hosts appeared again after runnig ssh-add ~/.ssh/id_rsa, so it was perfect.

[Hance J Tharakan (hancetharakan)]

I also came across with the above error message while using ssh.
I tried ssh in 2 machines in a loop. Only 1 showed(machine 21, below) the error. And in that machine(21)i had changed the password once before i ssh. So i think the error may be because of the password change.

Please note that ssh allows to login usig private/public key pair even after the password of the machine is changed.

See below the results...

[root@perfume2006 hance]# bash -x ./Desktop/Scripts/install 21 22
+ rm -rf out
+ x=21
+ '[' 21 -le 22 ']'
++ ping -w4 -q 10.107.3.21
++ grep packets
++ awk -v id=21 '{if ($6!="100%") print "10.107.3."id}'
+ m_id=10.107.3.21
+ scp -q /home/hance/Downloads/midsem_solutions_EE-733.pdf root@10.107.3.21:/home/pclab/Documents/
+ rsync -avz /home/hance/Downloads/test_program root@10.107.3.21:/home/pclab/Documents/
Agent admitted failure to sign using the key.
sending incremental file list

sent 37 bytes received 12 bytes 8.91 bytes/sec
total size is 75 speedup is 1.53
+ ssh root@10.107.3.21 /home/pclab/Documents/test_program
Agent admitted failure to sign using the key.
++ expr 21 + 1
+ x=22
+ '[' 22 -le 22 ']'
++ ping -w4 -q 10.107.3.22
++ awk -v id=22 '{if ($6!="100%") print "10.107.3."id}'
++ grep packets
+ m_id=10.107.3.22
+ scp -q /home/hance/Downloads/midsem_solutions_EE-733.pdf root@10.107.3.22:/home/pclab/Documents/
+ rsync -avz /home/hance/Downloads/test_program root@10.107.3.22:/home/pclab/Documents/
sending incremental file list

sent 37 bytes received 12 bytes 8.91 bytes/sec
total size is 75 speedup is 1.53
+ ssh root@10.107.3.22 /home/pclab/Documents/test_program
++ expr 22 + 1
+ x=23
+ '[' 23 -le 22 ']'
[root@perfume2006 hance]# bash -x ./Desktop/Scripts/install 22
+ rm -rf out
+ x=22
+ '[' 22 -le ']'
./Desktop/Scripts/install: line 3: [: 22: unary operator expected
[root@perfume2006 hance]# bash -x ./Desktop/Scripts/install 22 22
+ rm -rf out
+ x=22
+ '[' 22 -le 22 ']'
++ ping -w4 -q 10.107.3.22
++ grep packets
++ awk -v id=22 '{if ($6!="100%") print "10.107.3."id}'
+ m_id=10.107.3.22
+ scp -q /home/hance/Downloads/midsem_solutions_EE-733.pdf root@10.107.3.22:/home/pclab/Documents/
+ rsync -avz /home/hance/Downloads/test_program root@10.107.3.22:/home/pclab/Documents/
sending incremental file list

sent 37 bytes received 12 bytes 8.91 bytes/sec
total size is 75 speedup is 1.53
+ ssh root@10.107.3.22 /home/pclab/Documents/test_program
++ expr 22 + 1
+ x=23
+ '[' 23 -le 22 ']'

[Lorenzo (lsutton)]

I am experiencing this bug in Lucid when trying to connect (push) to github.
Running:

ssh-add

Solves works-around the problem for the session, in a terminal.

[Sebastian Rydberg (sr-rydbergtech)]

I had a similiar problem and I solved it with:

[srydberg@zeus ~]$ echo $SSH_AUTH_SOCK
/tmp/keyring-KXX3Aw/ssh
[srydberg@zeus tmp]$ sudo rm -rf keyring-KXX3Aw/

Maybe the keys are cached there?

[MountainX (dave-mountain)]

I have the same problem in Maverick

[ski (skibrianski)]

I don't think this problem is related to big-endianness. I just had it on a x86 system that was upgraded from feisty -> hardy -> lucid. In my case the fix was simple: apt-get install seahorse-plugins. For whatever reason that dependency doesn't seem to be pulled in when you upgrade. I'd recommend folks try that first if they are having problems.

[grolma (pdcooper)]

same problem for me for maverick x86 ( at both ends)

I think its to do with generating key and then replacing it

[drevicko (subscriptions-drevicko)]

Also on x86-64 with maverick.

Another post suggested looking at $SSH_AUTH_SOCK which is "/tmp/keyring-bp0Sgd/ssh" so indeed it seems to be a keyring problem.

I have gnome-keyring package version 2.92.92.is.2.31.91-0ubuntu4.1

The problem occurred just after re-creating my dsa key pair (I had inadvertently overwritten the old private key). After copying the private key into the host machines 'authorized_keys" file, ssh failed with:

  Agent admitted failure to sign using the key.
  Permission denied (publickey).

no request for the key's password was made.

running "ssh-add" re-requested the password for the key and subsequently ssh worked.

[Jacob Appelbaum (jacob-appelbaum)]

I'd like to confirm this bug too when using an SSH key with no passphrase.

I'm able to override the issue by running "SSH_AUTH_SOCK=0 ssh -v user@host"

Description: Ubuntu 10.04.1 LTS
Release: 10.04
Codename: lucid

[Jacob Appelbaum (jacob-appelbaum)]

I should note that this x86_64 and so clearly it's not a big endian bug for my machine.

[Jacob Appelbaum (jacob-appelbaum)]

If I install 'seahorse-plugins', I'm still not able to use this key and account without modifying SSH_AUTH_SOCK.

[Robert Grønning (slimg)]

$ lsb_release -r
Release: 10.10

$ uname -a
Linux milhouse 2.6.35-23-generic #41-Ubuntu SMP Wed Nov 24 11:55:36 UTC 2010 x86_64 GNU/Linux

$ ssh -v robert@remotehost
OpenSSH_5.5p1 Debian-4ubuntu5, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to remotehost [192.168.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/slimg/.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/slimg/.ssh/id_rsa-cert type -1
debug1: identity file /home/slimg/.ssh/id_dsa type -1
debug1: identity file /home/slimg/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-4ubuntu5
debug1: match: OpenSSH_5.5p1 Debian-4ubuntu5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr 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 'remotehost' is known and matches the RSA host key.
debug1: Found key in /home/slimg/.ssh/known_hosts:11
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/slimg/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
Agent admitted failure to sign using the key.
debug1: Trying private key: /home/slimg/.ssh/id_dsa
debug1: Next authentication method: password
robert@10.0.11.20's password:

$ SSH_AUTH_SOCK=0 ssh -v remotehost
OpenSSH_5.5p1 Debian-4ubuntu5, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to remotehost [192.168.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/slimg/.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/slimg/.ssh/id_rsa-cert type -1
debug1: identity file /home/slimg/.ssh/id_dsa type -1
debug1: identity file /home/slimg/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-4ubuntu5
debug1: match: OpenSSH_5.5p1 Debian-4ubuntu5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: ...

[David Baucum (maxolasersquad)]

I am having this same issue in Natty. In fact, this problem only occured after upgrading to Natty. Installing seahorse-plugins did not resolve the issue. Running ssh-add did resolve the issue.

[Birgir Hrafn (biggihs)]

Had the same issue in 10.04 LTS.
ssh-add resolved it.

[Doctor P (coffeeonmars)]

I have the same bug on 11.04, and can confirm that either setting SSH_AUTH_SOCK = 0, or deleting the directory it is pointing to (/tmp/keyring-something) solves the problem.

[imedina (imedina)]

Same bug on 11.04. I'm setting SSH_AUTH_SOCK = 0 to fix the problem.

[A.K.Karthikeyan (mindaslab)]

Confirming this bug on Ubuntu 11.04 as on 6th August 2011

[Dick Distortion (dickdistortion)]

Confirming on 11.10 also, setting SSH_AUTH_SOCK = 0 works.

[zhaoshun (353534480-j)]

yes 11.10

[tommyblue (tommaso-visconti)]

This bug affects 11.10 too.
Creating the key with a type different from rsa, e.g. dsa, fixes the problem.

[Woonjas (woonjas)]

Not sure if this is the same.
Connecting to my dreamplug running Ubuntu 9.04 from my laptop running 11.10 I'm getting the following (using ssh -vv)
....
debug1: Authentications that can continue: publickey
debug1: Offering DSA public key: app_81@localhost
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 433
debug2: input_userauth_pk_ok: fp d1:e6:cb:ee:07:cb:03:5c:ab:95:91:9a:71:20:2a:de
Agent admitted failure to sign using the key.
debug1: Trying private key: /home/nwestra/.ssh/id_rsa
debug1: Trying private key: /home/nwestra/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Using the same key from an ssh session on an old box running 9.10 works.

[unwrecker (unwrecker)]

same problem in 12.04
ssh-add doesn't help, but SSH_AUTH_SOCK=0 works

[s.a. (arndt-stephan)]

Same bug on 11.10, ssh-add solved it for me.

[Tomasz Sterna (smoku)]

I encountered this problem after upgrading to Precise 12.04 LTS

[Asif (vadud3)]

same problem in 12.04. unset SSH_AUTH_SOCK worked.

[madmaze (matthias-a-lee)]

For some reason this problem just cropped up for me on 12.04.1

As of last week the problem didnt exist, I believe something must have caused this in the last set of updates I installed.

[madmaze (matthias-a-lee)]

Actually, interestingly I just found:
ps aux | grep ssh-agent
madmaze 23158 0.0 0.0 13600 920 pts/8 R+ 20:24 0:00 grep --color=auto ssh-agent
madmaze 24080 0.0 0.0 0 0 ? Zs Nov02 0:14 [ssh-agent] <defunct>

I tried restarting ssh-agent but problem persists.
Though if i add SSH_AUTH_SOCK=0 it does solve the problem.

[madmaze (matthias-a-lee)]

it seems after a reboot it fixed itself again, so I assume it crashed for some reason.
I "grep"ed through /var/log for any indication of what caused the crash.. found nothing.

consider this resolved for me.

[linas (linasvepstas)]

I woke up this morning, and I get this error message. What happened?

-- it was working last night.
-- ssh-add -l says everything is there.
-- above means that ssh-agent is running
-- contents of /tmp and /tmp/keyring-XXX look OK
-- SSH_AUTH_SOCK=0 ssh wherever works

System: ubuntu 14.04
Uptime: about a month

Why is something that worked fine for a month suddenly stop working in the morning?

[Adam Katz (khopesh)]

Summary of problem (for me):

* ssh host fails with "ssh Agent admitted failure"
* SSH_AUTH_SOCK= ssh host works just fine
* Conclusion: gnome-keyring can't deal with complex keys

WORKAROUND:

mv $SSH_AUTH_SOCK $SSH_AUTH_SOCK.broken
ssh-agent -a $SSH_AUTH_SOCK

This is a new instance of ssh-agent, so it won't have any keys in it (despite what seahorse says, since that's tied to the .broken agent). You'll have to add them via ssh-add.

[Peter Ansell (p-ansell)]

The workaround of the following commands only works until I log out (not restarting the computer):

mv $SSH_AUTH_SOCK $SSH_AUTH_SOCK.broken
ssh-agent -a $SSH_AUTH_SOCK
ssh-add

When I log back in, without having to restart the computer, the SSH_AUTH_SOCK is corrupted again, and it seems to be consistent. If there are any commands I could run before and after logging out I am more than happy to contribute.

[Adam Katz (khopesh)]

Peter: Yes, that's all true (it's a workaround after all), though you could add the ssh-agent command to your startup scripts. I've updated my Stack Exchange answer <https://unix.stackexchange.com/a/189646/87770> to reflect that.

BTW, you don't actually need the `mv` line since the .broken socket isn't terribly useful.

[Adam Katz (khopesh)]

While this is not a big endian problem, it is a problem and it is NOT solved yet. I doubt it will be solved until Ubuntu bug 1420522 <https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/1420522> is solved.

This is GNOME bug 754028 <https://bugzilla.gnome.org/show_bug.cgi?id=754028>
(Among others, see https://bugzilla.gnome.org/buglist.cgi?no_redirect=0&quicksearch=ed25519#)

[api.ng (hektve)]

@admin_27966 @nuget @MyGetTeam @Github @VSTeam

[antisa (antisa)]

I would just like to add that this exact problem appears on Ubuntu phone (I have BQ Aquaris E5).

[Andreas Hasenack (ahasenack)]

According to https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/1420522 it's fixed in seahorse 3.30, which is present in ubuntu cosmic and later.

From https://bugzilla.redhat.com/show_bug.cgi?id=1435924, this should reproduce the problem:
1. Generate a ssh key using the keytype ed25519 and enter a password when creating the key:
$ ssh-keygen -t ed25519
2. Log out from your computer and log in again
3. Start a ssh session to a remote host:
$ ssh <email address hidden>

I tried that with bionic, which has seahorse 3.20.0

Comment #88 hints that trusty is affected and also broke, can someone confirm that please? trusty has seahorse 3.10.2-0ubuntu1

Releases older than trusty are EOL by now.

[Andreas Hasenack (ahasenack)]

Hi Petrida,

could you please elaborate on why you changed the bug status from incomplete to confirmed without providing the requested information from comment #95?