Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Can't figure this out - am using id_rsa key based authentication to our servers (approximately 400 Linux and UNIX servers).

In this case I have 3 identical servers with 3 recent installs of Ubuntu 12.04 - svr1 svr2 svr3 for the sake of this discussion.

They are IBM blade servers so I have the ability of logging into a remote console.

For svr1 I can ssh in fine using my rsa key - it looks like this from the client with ssh -vvv:

debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mbubb/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279 

and env vars are set and I am in...

But for svr2 (and 3) it looks like this:

debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/mbubb/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering DSA public key: /home/mbubb/.ssh/id_dsa

... it cycles through other key options and finally:

   debug2: we did not send a packet, disable method
   debug1: No more authentication methods to try.
   Permission denied (publickey).

What is curious is if I console in through the Bladecenter MM and then ssh to the server it works fine.

Looking at /var/log/auth.log on svr2 there are no entries for when I get "Permission denied". It doesn't appear to 'see' the attempt.

I checked directory permissions (homedir and sshdir) they are consistent. I compared /etc/ssh/sshd_config - they are identical.

Maybe it is PAM? Or another level of authentication.

I am intrigued by this - obviously there is something basic here I am not getting...

share|improve this question
    
Should have looked in 'superuser' superuser.com/questions/318233/… –  user150755 Dec 23 '12 at 16:51
add comment

1 Answer

up vote 5 down vote accepted

If you're using an encrypted home directory, then the fix is to set up an alternate authorized_keys location by setting

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

in the server's sshd_config file so it looks somewhere other than the user's home directory for the file.

The file can be located anywhere, but you have to have the %u to separate users' files into their own directories so that sshd will find appropriate permissions for the directory and file.

share|improve this answer
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.