Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have two machines with the same .ssh/authorized_keys (verified since (1) one is a copy of the other and (2) the md5sums of the file on both machines match)

and the same /etc/ssh/sshd_config (verified since (1) one is a copy of the other and (2) md5sums match).

sshd was restarted on both machines.

One works (using the publickey method, ie. I'm able to log in w/o having to type in a password) and the other doesn't.

Running ssh -vv shows the following:

Good machine displays:

debug1: Offering DSA public key: /Users/xxx/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 433
debug2: input_userauth_pk_ok: 
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
Authenticated to xxx.amazonaws.com ([xxx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

Bad machine displays:

debug1: Offering DSA public key: /Users/xxx/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

Any thoughts?

share|improve this question

migrated from stackoverflow.com Feb 7 '13 at 7:03

This question came from our site for professional and enthusiast programmers.

    
Check that the permissions on your home directory are 755, and that the permissions on your ~/.ssh directory are 700, and that the permissions on authorized_keys are 600. –  Nitzan Shaked Feb 3 '13 at 4:11
    
Home dir is 755 on both. For both machines ~/.ssh is 775 and authorized_keys is 664. The version of ssh is the same for both machines: OpenSSH_6.0p1 Debian-3ubuntu1, OpenSSL 1.0.1c 10 May 2012 –  Russell Feb 3 '13 at 4:16
    
Changing .ssh to 700 and authorized_keys to 600 worked. But why does it work on the "good machine"? –  Russell Feb 3 '13 at 4:32
add comment

1 Answer

See comments: "Changing .ssh to 700 and authorized_keys to 600 worked. But why does it work on the 'good machine'?"

share|improve this answer
add comment

Your Answer

 
discard

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