Is there any way to verify why SSH key exchange between 2 servers is not working?

In Server A: I did the following steps:

ssh-keygen –t rsa
cd /.ssh
cp id_rsa.pub authorized_keys

Then in Server B: I created the .ssh directory and uploaded the authorized_keys from Server A

I tried logging in from Server A to Server B but the system is still prompting me to enter password.

I tried using this: On server(A) you connect via ssh user1@host? You might try ssh -o PreferredAuthentications=publickey user1@host but it show permission denied Permission denied (gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive).

Any advise on how to check what is wrong? Just additional info in Server A i am not using the root account.

link|improve this question

0% accept rate
I tried using this: On server(A) you connect via ssh user1@host? You might try ssh -o PreferredAuthentications=publickey user1@host but it show permission denied Permission denied (gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive). – dfdfd Oct 10 '11 at 9:07
feedback

5 Answers

Check the permissions of the serverb authorized_keys file. If it has write permission for group/other then login using public keys will fail and fall back to password if it's available. If required change the permissions on the authorized_keys file to 644.

Possible but less likely is that you have public key authentication disables in your /etc/ssh/sshd_config file. Check that the config file does not contain a line

PubkeyAuthentication no

IF it does just comment it out (the default is yes) and restart the sshd service.

link|improve this answer
1  
And the permissions on serverB:~/.ssh should be 700. – MadHatter Oct 6 '11 at 11:17
+1 also check the file owner, it has to be the user who is logging in. – Chris S Oct 6 '11 at 12:31
Permissions on authorized_keys should be 600, not 644. – slillibri Oct 6 '11 at 21:28
@slillibri With perms at 644 you can still log in so sshd disagrees with you. – Iain Oct 6 '11 at 21:30
feedback

Try ssh -v this should provide additional information about the authentication process.

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive,hostbased
debug1: Offering RSA public key: /home/nce/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277

Just to confirm your steps: You created a keypair via ssh-keygen Then you uploaded the key at .ssh/id_rsa.pub to the server(B) and appended it to the .ssh/authorized_keys for the user1.

On server(A) you connect via ssh user1@host? You might try ssh -o PreferredAuthentications=publickey user1@host

And you could provide a special/different identityfile by ssh -i ~/.ssh/serverB/id_rsa user1@host

link|improve this answer
I tried using this: On server(A) you connect via ssh user1@host? You might try ssh -o PreferredAuthentications=publickey user1@host but it show permission denied Permission denied (gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive). – dfdfd Oct 10 '11 at 9:06
feedback

A tip for you: take a look at serverB's sshd log (/var/log/secure on Red Hat based)

http://www.openssh.org/faq.html#3.14

And for the future, you should use ssh-copy-id instead of manual copy.

link|improve this answer
feedback

This command should not work:

cd /.ssh

Is that a typo or were you in the wrong place when you copied the id_rsa.pub file to authorized_keys?

Log into server B and cat ~/.ssh/authorized_keys to see if it contains what is in the same file on server A.

Note, it is not important that you keep the authorized_keys file on server A as it is not used in the authentication transaction from server A to server B. You just need the id_rsa file in ~.ssh/ on server A.

link|improve this answer
feedback

Check to see whether sshd on B is configured to accept key-based authentication. On RedHat based systems the config file is /etc/ssh/sshd_config.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.