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

Bug #201786 reported by sam tygier
380
This bug affects 80 people
Affects Status Importance Assigned to Milestone
seahorse
Fix Released
Critical
gnome-keyring (Ubuntu)
Fix Released
Low
Unassigned
openssh (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

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.

Tags: 14.04 14.10
Revision history for this message
Nicolas Valcarcel (nvalcarcel) wrote :

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.

Changed in openssh:
status: New → Incomplete
Revision history for this message
Colin Watson (cjwatson) wrote :

Is there a process called seahorse running?

Revision history for this message
sam tygier (samtygier) wrote :
Download full text (3.9 KiB)

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

Read more...

Revision history for this message
Marcus Asshauer (mcas) wrote :

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

Changed in openssh:
status: Incomplete → Confirmed
Revision history for this message
Berend De Schouwer (berend-de-schouwer) wrote :

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

Revision history for this message
fish (discordianfish) wrote :

Same problem here, unsetting SSH_AUTH_SOCK works too.

Revision history for this message
Nelson Pavlosky (nelson-freeculture) wrote :

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?

Changed in seahorse:
status: Unknown → New
Changed in seahorse:
status: New → Confirmed
Revision history for this message
Allison Karlitskaya (desrt) wrote :

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

Revision history for this message
John Steele Scott (toojays) wrote :

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.

Changed in gnome-keyring:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Confirmed → Triaged
Revision history for this message
feiy (eshangrao) wrote :

Confirm in Ubuntu intrepid

set SSH_AUTH_SOCK=0 can fixed it!

Revision history for this message
Sarah Kowalik (hobbsee-deactivatedaccount) wrote :

also getting this here.

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

Revision history for this message
Martin Maney (maney) wrote :

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.

Revision history for this message
Martin Pitt (pitti) wrote :

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

Revision history for this message
Brian Murray (brian-murray) wrote :

I am experiencing this bug on an amd64 machine.

Revision history for this message
Brian Murray (brian-murray) wrote :

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

Revision history for this message
sam tygier (samtygier) wrote :

i was on powerpc (big endian).

Revision history for this message
zcrar70 (eliemedeiros) wrote :

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:

Revision history for this message
zcrar70 (eliemedeiros) wrote :

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

Revision history for this message
Unca Xitron (benny-egovmt) wrote :

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.

Revision history for this message
pat.pannuto (ppannuto) wrote :

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.

Revision history for this message
pat.pannuto (ppannuto) wrote :

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

Revision history for this message
zcrar70 (eliemedeiros) wrote :

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.

Revision history for this message
Unca Xitron (benny-egovmt) wrote :

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.

Revision history for this message
Jeffrey Baker (jwbaker) wrote :

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

Revision history for this message
adinsx (adinsx3) wrote :

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.

Revision history for this message
adinsx (adinsx3) wrote :

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.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

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

:-Dustin

Changed in openssh:
status: New → Confirmed
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

the jaunty issue is likely a different one

Revision history for this message
Anand Kumria (wildfire) wrote :

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

Revision history for this message
Dustin Kirkland  (kirkland) wrote : Re: [Bug 201786] Re: ssh Agent admitted failure to sign using the key on big endian machines

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

:-Dustin

Revision history for this message
Tim Utschig (tim-magnumsemi) wrote :

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

Revision history for this message
Unca Xitron (benny-egovmt) wrote :

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

Revision history for this message
Christian Albrecht (christian-urban-souls) wrote :

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.

Revision history for this message
Hendy Irawan (ceefour) wrote : apport-collect data

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

Revision history for this message
Hendy Irawan (ceefour) wrote :
Revision history for this message
Cédric Jeanneret deactivated (cjeanneret-c2c-deactivated) wrote :

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.

Revision history for this message
Patrick Walker (phobiac) wrote :

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?

Revision history for this message
Cédric Jeanneret deactivated (cjeanneret-c2c-deactivated) wrote :

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.

Revision history for this message
Austin English (austinenglish) wrote :

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

Revision history for this message
TheTom (tomgey) wrote :

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

Revision history for this message
TheTom (tomgey) wrote :

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

Revision history for this message
James Clemence (jvc26) wrote :

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

Revision history for this message
Alexander Telenga (telenga) wrote :

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

Revision history for this message
Marco Diaz (zethabyte) wrote :

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

Revision history for this message
Eric Stein (estein) wrote :

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.

Revision history for this message
AlainODea (alain-odea) wrote :

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'

Revision history for this message
AlainODea (alain-odea) wrote :

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.

Revision history for this message
demizer (jeezusjr) wrote :

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.

Revision history for this message
sionib (sionib) wrote :

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

Revision history for this message
Jeff Hatfield (nomasteryoda) wrote :

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.

Revision history for this message
Mikko Ohtamaa (mikko-red-innovation) wrote :

Utterly annoying.

As a workaround put line

export SSH_AUTH_SOCK=0

to

/home/YOURUSERNAME/.bashrc file.

Works for terminal sessions only, though.

Revision history for this message
Oded Arbel (oded-geek) wrote :

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.

Revision history for this message
bitinerant (bitinerant) wrote :

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.

Revision history for this message
Stuardo -StR- Rodríguez (stuardo) wrote :

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

Revision history for this message
Tim Utschig (tim-magnumsemi) wrote : Re: [Bug 201786] Re: ssh Agent admitted failure to sign using the key on big endian machines

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: 408-644-3861

Revision history for this message
Portable-Jim (christian-chess-geek) wrote :

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.

Revision history for this message
Ray (bernhard-posselt) wrote :

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

Changed in seahorse:
importance: Unknown → Critical
Revision history for this message
Pavel Strakhov (strahovp) wrote :

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

Revision history for this message
poloshiao (poloshiao) wrote :

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.

Revision history for this message
Hance J Tharakan (hancetharakan) wrote :

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 ']'

Revision history for this message
Lorenzo (lsutton) wrote :

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.

Revision history for this message
Sebastian Rydberg (sr-rydbergtech) wrote :

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?

Revision history for this message
MountainX (dave-mountain) wrote :

I have the same problem in Maverick

Revision history for this message
ski (skibrianski) wrote :

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.

Revision history for this message
grolma (pdcooper) wrote :

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

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

Revision history for this message
drevicko (subscriptions-drevicko) wrote :

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.

Revision history for this message
Jacob Appelbaum (jacob-appelbaum) wrote :

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

Revision history for this message
Jacob Appelbaum (jacob-appelbaum) wrote :

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

Revision history for this message
Jacob Appelbaum (jacob-appelbaum) wrote :

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

Revision history for this message
Robert Grønning (slimg) wrote :
Download full text (4.3 KiB)

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

Read more...

Changed in seahorse:
status: Confirmed → Fix Released
Revision history for this message
David Baucum (maxolasersquad) wrote :

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.

Harpianto,ANDI (amhnews)
Changed in gnome-keyring (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → ANDI MUHAMMAD HARPIANTO (amhnews)
assignee: ANDI MUHAMMAD HARPIANTO (amhnews) → nobody
Revision history for this message
Birgir Hrafn (biggihs) wrote :

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

Revision history for this message
Doctor P (coffeeonmars) wrote :

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.

Revision history for this message
imedina (imedina) wrote :

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

Revision history for this message
A.K.Karthikeyan (mindaslab) wrote :

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

Revision history for this message
Dick Distortion (dickdistortion) wrote :

Confirming on 11.10 also, setting SSH_AUTH_SOCK = 0 works.

Revision history for this message
zhaoshun (353534480-j) wrote :

yes 11.10

Revision history for this message
tommyblue (tommaso-visconti) wrote :

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

Revision history for this message
Woonjas (woonjas) wrote :

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.

Revision history for this message
unwrecker (unwrecker) wrote :

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

Revision history for this message
s.a. (arndt-stephan) wrote :

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

Revision history for this message
Tomasz Sterna (smoku) wrote :

I encountered this problem after upgrading to Precise 12.04 LTS

Revision history for this message
Asif (vadud3) wrote :

same problem in 12.04. unset SSH_AUTH_SOCK worked.

Revision history for this message
madmaze (matthias-a-lee) wrote :

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.

Revision history for this message
madmaze (matthias-a-lee) wrote :

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.

Revision history for this message
madmaze (matthias-a-lee) wrote :

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.

Revision history for this message
linas (linasvepstas) wrote :

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?

Revision history for this message
Adam Katz (khopesh) wrote :

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.

Bib (bybeu)
tags: added: 14.04
tags: added: 14.10
Revision history for this message
Peter Ansell (p-ansell) wrote :

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.

Revision history for this message
Adam Katz (khopesh) wrote :

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.

Revision history for this message
Adam Katz (khopesh) wrote :

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

Revision history for this message
api.ng (hektve) wrote :

@admin_27966 @nuget @MyGetTeam @Github @VSTeam

Revision history for this message
antisa (antisa) wrote :

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

Changed in openssh (Ubuntu):
assignee: nobody → Ngo Quang Thong (quangthong1981)
Robie Basak (racb)
Changed in openssh (Ubuntu):
assignee: Ngo Quang Thong (quangthong1981) → nobody
Lisa byron (mark201)
Changed in gnome-keyring (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

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.

Changed in openssh (Ubuntu):
status: Confirmed → Incomplete
Changed in openssh (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

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?

Changed in openssh (Ubuntu):
status: Confirmed → Incomplete
To post a comment you must log in.
This report contains Public information  
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.