Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

A user (user1) on an Ubuntu 12.04 desktop has two SSH RSA keys configured: ~/.ssh/id_rsa and ~/.ssh/id_rsa1 (and .pub files). Both public keys are configured in the authorised keys on the server's account (user1@myserver).

When logged on to the desktop (client) machine, and using a Gnome Terminal, logging on to the server using either keys works fine:

  • ssh user1@myserver implicitly picks up /home/user1/.ssh/id_rsa
  • ssh -f /home/user1/.ssh/id_rsa1 user1@myserver also works.

If, instead of logging on via the Gnome Desktop, I log on to the client machine via SSH from another host (or even localhost) or use su, using /home/user1/.ssh/id_rsa no longer works.

This appears to have something to do with SSH_AUTH_SOCK (missing originally in the environment set up with an SSH connection to the client). If I set it up to be the value visible in the desktop session /tmp/keyring-xxxxxxxxxxx/ssh, logging in with id_rsa works fine again.

If I unset SSH_AUTH_SOCK (to make logging with id_rsa fail again), and copy id_rsa1 to id_rsa (and .pub files), it now works with id_rsa too.

What can explain the difference of behaviour between those two key pairs and their interaction with SSH_AUTH_SOCK?

I can't see anything in the server logs.

Here is the fragment of the SSH client logs, just before it differs:

debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user1/.ssh/id_rsa (0x7f6b7059b260)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/user1/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply

Followed by this, when it doesn't work for that user/key:

debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
share|improve this question

2 Answers 2

up vote 3 down vote accepted

It turns out that the key that didn't work wasn't configured properly in the authorized_keys file after all. Sorry about that...

I wrongly assumed that ssh -i /home/user1/.ssh/id_rsa user1@myserver was an indication that it was configured properly, but this turns out not to be the case. It makes use of other keys too. Forcing ssh -i /home/user1/.ssh/id_rsa -oIdentitiesOnly=yes user1@myserver makes it fail with the incorrect configuration too.

I guess the SSH agent set up when logging on with Gnome also picks up other keys in the ~/.ssh/ directory, which makes it work with that other key, even if the wrong key is specified with -i.

share|improve this answer

I don't actually use gnome, but chances are it's trying to communicate to an ssh-agent (or even starting one for your convenience).

You didn't mention whether or not your keys are passwordless.

Another things that MAY have gone wrong in the copy is the permissions on a) user2's /home, b) their .ssh or c) the authorized_keys file.

share|improve this answer
    
Yes, these keys are passwordless. It seems it has something to do with the agent, but it doesn't seem related to the permissions, since the it works with -i ~/.ssh/id_rsa1, and with -i ~/.ssh/id_rsa and SSH_AUTH_SOCK set up (from user1). What I don't understand is why one of the files would require an agent but not the other. –  Bruno Oct 22 '12 at 19:15
    
It turns out it was a configuration mistake indeed. Not quite detectable the way I expected, but a mistake from my side unfortunately. Thanks for your help anyway. –  Bruno Oct 22 '12 at 20:51

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.