SSH keys fail for one user

Question

I just set up a new Debian server. I disabled root SSH and password auth, so you've gotta use a key file.

For my primary user, everything works exactly as expected. I used ssh-keygen -t dsa and got myself a public and private key. Put one in authorized keys, put the other in a pem file locally.

I wanted to create a user that I can deploy things with, so I did basically the same process. I addusered it, made a .ssh folder, ran ssh-keygen -t dsa (I also tried RSA), put the keys in their appropriate locations.

No luck. I'm getting a Permission denied (publickey) error. When I use the exact same keys as the account that works, same error. When I enable password authentication, I can log in via SSH with the password.

How do I debug this?

EDIT

Verbose ssh output (deployer.pem is proper key):

 debug2: key: /Users/eli/.ec2/deployer.pem (0x100126830) debug2: key: /Users/eli/.ec2/deployer.pem (0x100126b30) debug2: key: /Users/eli/.ec2/deployer.pem (0x0) debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred 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 public key: /Users/eli/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Offering public key: eli.pem debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Offering public key: /Users/eli/.ec2/deployer.pem debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Offering public key: /Users/eli/.ec2/deployer.pem debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Trying private key: /Users/eli/.ec2/deployer.pem debug1: read PEM private key done: type DSA debug3: sign_and_send_pubkey debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey). 

Answer 1

Two parts: first, turn up debugging on your ssh sever. Edit /etc/ssh/sshd_config and increase LogLevel to DEBUG. Then force your ssh server to reload it's config with killall -HUP <sshd pid>.

That will cause the server to add much more details to your /var/log/secure and/or /var/log/auth logfiles.

Secondly (actually you cant try this first), increase the debug level on the client side. ssh in to the box with

$ ssh -vvv hostname

and that will print out lots more info about where the process is failing.

If you do turn up the debug level on your ssh server, don't forget to turn it back down when you are finished.

Answer 2

Have you checked the permissions on the key files? The .ssh/id_dsa file should be 600 and owned by the user. Run ssh -v root@host to see if this is the problem.

Answer 3

If the user's home directory, the .ssh directory under the user's home directory, or the user's authorized_keys file are writable by anyone other than the user (either group or other), key authentication will outright fail because the .ssh/authorized_keys file can no longer be trusted (as another user could then replace or modify it and thus log in as that user).

Try:

chmod go-w ~USER ~USER/.ssh ~USER/.ssh/authorized_keys 

and see if that clears up your problem.

Answer 4

chown -R username. /home/username/.ssh

chmod 700 /home/username/.ssh

chmod 400 /home/username/.ssh/id_dsa /home/username/.ssh/id_dsa.pub

chmod 600 /home/username/.ssh/authorized_keys

Answer 5

Here are a few tips based on the issues I ran into while trying to get ssh working via Pubkey Authentication ie ssh rsa:

in addition to the above tips (permissions, -vvv): - on the destination server, check the account info via passwd -S username or passwd -s username. The output will look like [username][stat][pwchg][min][max][warn]. if the [stat] column says LK, you need to unlock the account passwd -u username. if the [pwchg] date is older than [max] days, you need to change the max days or change the password on username via passwd -x 999 or passwd username

example:

# uname -n myserver # pwd /export/home/santac # ls -l .ssh -rw------- 1 santac users 796 Jul 8 00:27 authorized_keys # cat .ssh/authorized_keys ssh-rsa AAABBBCCCboogaboogaAAABBBCCCidonthinkyougetthatthisisbogusbutwhattheheck== santac@otherserv # date Wed Jul 8 00:55:10 GMT 2015 # passwd -S santac santac LK 03/05/14 7 60 10 (note stat is LK or locked) # passwd -u santac # passwd -S santac santac PS 03/05/14 7 60 10 (note [pwchg] date is older than 60 days) # passwd santac Enter New Password: Confirm New Password: # passwd -S santac santac PS 07/08/15 7 60 10 (all good now) FROM THE OTHER SERVER: # uname -n otherserv # pwd /export/home/santac # ls -l .ssh -rw------- 1 santa users 1675 Jul 6 20:23 id_rsa -rw------- 1 santa users 394 Jul 6 20:23 id_rsa.pub # cat .ssh/id_rsa.pub ssh-rsa AAABBBCCCboogaboogaAAABBBCCCidonthinkyougetthatthisisbogusbutwhattheheck== santac@otherserv LOOKS GOOD...