Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Ok... so when I try to ssh into my hosting service's shell account, I cannot login. The problem seems to be the Gnome Keyring service not having a supported key algorithm, but I'm clueless as to how to fix this and I'm wasting way too much time Googling for answers that nobody seems to have. One site said that installing the libpam-unix2 package should fix the problem, but it didn't fix anything for me.

Hopefully someone here has a clue. Here's what's happening (I'm using Ubuntu 12.04)....

$ rm -R .ssh
$ ssh -v ###.###.###.###
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ###.###.###.### [###.###.###.###] port 22.
debug1: Connection established.
debug1: SELinux support disabled
debug1: identity file /home/forrest/.ssh/id_rsa type -1
debug1: identity file /home/forrest/.ssh/id_rsa-cert type -1
debug1: identity file /home/forrest/.ssh/id_dsa type -1
debug1: identity file /home/forrest/.ssh/id_dsa-cert type -1
debug1: identity file /home/forrest/.ssh/id_ecdsa type -1
debug1: identity file /home/forrest/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
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: Server host key: RSA f4:a8:f7:88:56:bd:6e:87:73:3d:45:12:8d:c2:eb:c0
The authenticity of host '###.###.###.### (###.###.###.###)' can't be established.
RSA key fingerprint is f4:a8:f7:88:56:bd:6e:87:73:3d:45:12:8d:c2:eb:c0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '###.###.###.###' (RSA) to the list of known hosts.
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: Trying private key: /home/forrest/.ssh/id_rsa
debug1: Trying private key: /home/forrest/.ssh/id_dsa
debug1: Trying private key: /home/forrest/.ssh/id_ecdsa
debug1: Next authentication method: password
forrest@###.###.###.###'s password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
forrest@###.###.###.###'s password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
forrest@###.###.###.###'s password: 
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
Permission denied (publickey,password).

The relevant bit in /var/logs/auth.log says --

Aug 11 09:01:17 pompano gnome-keyring-daemon[16231]: unsupported key algorithm in certificate: 1.2.840.10045.2.1
Aug 11 09:02:33  gnome-keyring-daemon[16231]: last message repeated 4 times

So apparently the gnome keyring no longer has the supported key algorithm for SSH? Huh?

share|improve this question
    
Is the private key in one of the files listed in your debug messages from ~/.ssh/? If so, which one? Have you tried to unset SSH_AUTH_SOCK so ssh will forget about the gnome-keyring? –  John S Gruber Aug 11 '12 at 13:36
add comment

1 Answer

John S Gruber's post should help. Do:

env | grep SSH_AUTH_SOCK

Check the value of the variable to see whether that file exists. If it does:

unset SSH_AUTH_SOCK

That should remove the socket file; if not, you may need to remove it manually (as sudo).

share|improve this answer
    
A simpler way to check the variable's value is echo $SSH_AUTH_SOCK. –  Eliah Kagan Aug 13 '12 at 20:29
    
unsetting SSH_AUTH_SOCK didn't work for me. But, I discovered that it was trying to log me in with the wrong username. It was using "Forrest", which is my username on my laptop, but not on the server I'm trying to connect to. When I ssh dfy@##.##.##.##, then it all works smoothly. I didn't expect that. So, the solution is that I simply have to use the username in the commandline... didn't realize that. Sorry I asked a stupid question. :-P –  Zamphatta Aug 16 '12 at 16:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.