openssh-client (amd64) can't login after upgrade to jaunty

[Hadmut Danisch]

Binary package hint: openssh-client

Hi,

I've just upgraded an AMD64 machine from intrepid to jaunty, and since then my ssh-client can't login to a debian machine with its sshd anymore. The secret key is not accepted anymore. The client just says that the server did not accept the public key. The (unmodified) debian server has for each login attempt an entry in the log

sshd[680]: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)

The login still worked two hours ago, just until the upgrade from intrepid to jaunty.

Interestingly, I did not see that problem on an x86 machine where I did the same upgrade. Seems to be an AMD64 specific bug in the crypto stuff.

regards

[Colin Watson (cjwatson)]

Could you post ssh -vvv output please?

[Hadmut Danisch (hadmut)]

ok, is attached. btw, the ssh login fails even if I try login to localhost, i.e. to the ubuntu machine itself.

I had an RSA key only, the one that failed ufter upgrade.
I could workaround by generating an dsa key, which works.

Might be related to debian bug #357998

I am not really sure whether this really caused by the AMD64 architecture, it could also be a property of the rsa key, which causes trouble.

regards

[Colin Watson (cjwatson)]

$ openssl errstr 0407006A
error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01

[Colin Watson (cjwatson)]

Likely, though not certain, to be a bug in openssl rather than openssh.

[Colin Watson (cjwatson)]

Surely you don't mean Debian bug #357998? It's a different bug, and I find the coincidence of a Debian bug report with the same bug number as the corresponding Ubuntu bug report a bit hard to swallow :-)

[Colin Watson (cjwatson)]

Since you can reproduce this on a machine you control, could you also run 'sudo /etc/init.d/ssh stop', then run 'sudo /usr/sbin/sshd -ddd', try connecting to it to reproduce this bug, and post the output of that?

[Hadmut Danisch (hadmut)]

Here it is...

[Nathan Clemons (nathanclemons)]

This happens for me on i686 as well after upgrading from Intrepid to Jaunty. It appears to be related to seahorse-agent rather than the openssh-client.

If I run:

SSH_AUTH_SOCK=0 ssh localhost

I am prompted for my passphrase for my key and it authenticates me fine.

If I run:

eval `ssh-agent`
ssh-add -i ~/.ssh/id_rsa

And enter my passhrase, then ssh localhost, everything works fine.

Seahorse-agent is running, and if I do an ssh-add -l I see my key there just fine, but something it presents to the remote server is not accepted by ssh.

[greg_s50 (gregs50)]

Hi,

I've go the same problem.

Upgrade 8.04 64bits to 9.04 bits and I've got Debian server (Lenny 64bits)

On my server this error was report on /var/log/auth.log

"sshd[7864]: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)"

[Andreas Heinlein (aheinlein)]

I am also having the exact same problem, on x86, right after upgrading from intrepid to jaunty. I can also confirm that the workaround by Nathan works. I am pretty sure it is a problem with seahorse, because nothing has changed on the server or with the key. I can login from another machine with the same key just fine.

[Vasil Kolev (vasil-ludost)]

Another workaround seems to be to disable gnome messing in the key management - with the gconf-editor go to apps/gnome-keyring/daemon-components and disable 'ssh'. A few colleagues are using this (on x86) and it works.

[Jonathan Matthews (matthewslevine+launchpad)]

This is also present on x86, as per attachment.

[Matt Keenan (tank.en.mate)]

I have found this <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483838">bug</a> in Debian. I know for me that I use a 2039 bit RSA key to reduce the chance of a differential analysis attack. I will check with a 2048 bit key and see if this fixes the problem.

[Andreas Heinlein (aheinlein)]

I can confirm that it worked again using a newly generated 2048bit RSA key. I had a 2047 Bit key before.

[Hendy Irawan (ceefour)]

Architecture: i386
DistroRelease: Ubuntu 9.04
Package: openssl 0.9.8g-15ubuntu3
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

[captwiggum (captwiggum)]

Same here. ssh / authorized_keys was working fine for rsa logins with Ubuntu 8.10 on AMD arch.
I upgraded to 9.04 on my desktop, and now I can not login to my server with my rsa key.

May 24 09:26:29 sshd[25434]: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)

My server has not changed. My key has not changed. My key bit length is 1999 bits.

The one theme I see in the above thread is non-standard key bit length. Sounds like a bug to me.

[captwiggum (captwiggum)]

My testing is same a others. I had to traverse two bugs to find solution.

SUMMARY:
* After upgrade to 9.04, can not ssh with rsa keys.
* Using my pre-existing non-standard bit length rsa key (1999), ssh to host generates this error in /var/log/messages: "error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)"
* Taking advice from this list, I created a new standard bit length rsa key (2048 in this case), and updated new pub key on host in authorized_keys. Then when I ssh to host, the ssh client says: "Agent admitted failure to sign using the key"

SOLUTION:
by-pass local ssh-agent with this:
export SSH_AUTH_SOCK=dsasdflkasdfljkasdflkj

Now it allows me to successfully ssh to my host with rsa keys. From reading other's reports, it seems like this error is in the ssh client and not the ssh-agent nor openssl. It occurs even if I stop ssh-agent. But that's just my impression. I'm sure there will be an updated package soon.

Related Bugs:
[Jaunty/amd64] Agent admitted failure to sign using the key. bug #328445
gnome-keyring-daemon returns Agent admitted failure to sign using the key. bug #328127

Hope this helps someone.

[Maarten Bezemer (veger)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running apport-collect 357998 and any other logs that are relevant for this particular issue.