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

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).
share|improve this question
    
Try ssh -v user@host to get more debug output from the client. (and ssh -vv for even more). –  SmallClanger Jan 10 '11 at 18:54
    
Look in the server logs for hints. –  Bill Weiss Jan 10 '11 at 19:38

4 Answers 4

up vote 3 down vote accepted

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.

share|improve this answer
    
Thanks for the debugging help, the real issue was the my .ssh directory on the server had crazy permissions. All of the files in it had the correct permissions, though. –  Eli Jan 10 '11 at 19:06

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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.