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'm trying to set-up a password-less login for SSH to script some automated tests on my system.

I need to set this up for two different machines, so from machine "A" I need to use password-less login for machines "B" and "C".

I've run the following, which works for machine "B", but not for machine "C".

me@A# ssh-keygen
... [ follow the instructions just pressing Enter ]
me@A# ssh-copy-id -i ~/.ssh/id_rsa.pub root@B
... [ enter password when requested, etc.]
me@A# ssh root@B
Last Login XXX from YYY
root@B#

So this works fine for machine "B". If I follow exactly the same procedure for machine "C", then it doesn't work.

Both machines are Scientific Linux 6.4, up-to-date and I've run "telnet B 22" and "telnet C 22" to determine which version of SSH is running on each machine ("SSH-2.0-OpenSSH_5.3"). I diff'd the /etc/ssh/sshd_config files on machines B and C. They are identical.

I've tried starting with machine "C", I've been careful to clear out the ".ssh" directory on all three machines each time I start a new test, but I get the same result each time. "B" works, "C" doesn't - it asks for the password still (but then let's me in, at least)

I'm looking for a specific tests to try to find out what the difference between these two machines is that will make this work for one machine but not the other. They're in identical boxes even. One has 1GB memory, one has 4Gb. That's about the only physical difference.

share|improve this question

2 Answers 2

up vote 2 down vote accepted

Check the permissions on the .ssh directory of the remote machine, and the authorized_keys file in that directory. These should only be readable by the user you're using to ssh, thus ".ssh" should have permissions 0700 and "authorized_keys" 0600, and these need to have the correct ownership.

You can also use the "-vvv" argument to your ssh command to see if the correct key is being offered as part of the authentication and where the process stops and falls back to password

share|improve this answer
    
That certainly seems to be getting me closer. I tried using -vvv and I get this on machine "C": debug1: Next authentication method: publickey debug1: Offering public key: me@C debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug3: Wrote 368 bytes for a total of 1645 debug1: Server accepts key: pkalg ssh-rsa blen 277 Machine "B" has identical messages, except the final "debug1" message doesn't appear. "B" authenticates at that point. Is my ssh client sending the same public key to both machines? If it is, is that allowed? –  user1738833 Dec 19 '13 at 13:28
    
Sorry - swap "C" and "B" above. The messages are from "B", which authenticates, not "C" –  user1738833 Dec 19 '13 at 13:34
    
Do you see a line like "debug1: Next authentication method: password" in the one that fails? If you have identical keys in .ssh/authorized_keys on B and C then using the same private key you generated should work on both. Did you verify the file permissions too? If so, you may have some different settings somewhere deeper in the auth subsystem –  arco444 Dec 19 '13 at 14:27

On machine C you can try to stop the sshd service and run the ssh daemon in debug mode. You can do this while logged on via SSH, just make sure you keep an extra session to restart the sshd service from. You can start sshd in debug mode with:

$ service sshd stop
$ /usr/sbin/sshd -d

Then try to log on to the server, and the debug output will most likely tell you what the problem is. Don't forget to reenable the sshd service when you're done.

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.