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

Trying to SSH in to remote computer but still asking for password.

I have a number of computers running SElinux and only one of them is giving me a hard time using ssh without the password.

I did a ssh-copy-id and I can see my key in the .ssh/authorized_keys.

I chmod 700 .ssh and chmod 600 all the files in ./ssh/*

If i do a ssh -v this is my output:

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to wcmisdlin05 [10.52.208.224] port 22.
debug1: Connection established.
debug1: identity file /home/jsmith/.ssh/identity type -1
debug1: identity file /home/jsmith/.ssh/id_rsa type 1
debug1: identity file /home/jsmith/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'wcmisdlin05' is known and matches the RSA host key.
debug1: Found key in /home/jsmith/.ssh/known_hosts:9
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Offering public key: /home/jsmith/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/jsmith/.ssh/identity
debug1: Trying private key: /home/jsmith/.ssh/id_dsa
debug1: Next authentication method: password

Can someone please tell me why its not working on this one remote computer?

share|improve this question
2  
Look in /var/log/secure (if it's permissions) & /var/log/messages (if it's SELinux.) Otherwise, it's a mismatch between what's in ~/.ssh/authorized_keys and what is being sent by the SSH client. –  Aaron Copley Jan 9 '13 at 14:46
add comment

4 Answers

I've often encountered a similar bug on CentOS 6 machines involving ssh-copy-id and SELinux.

When ssh-copy-id creates the authorized keys files it creates it with the proper permissions, but with the wrong SELinux label. The fix for this is restoring the labels to their policy defaults using this command:

restorecon -R ~/.ssh

share|improve this answer
add comment

These things are always much easier debugged from the server side, if that is possible. If you can start a sshd on another port in debug mode, it will tell you immediately why the key is being rejected (my wild guess is that your home directory is group writable). You can, for example, start a sshd in debug mode on port 2222 with /usr/sbin/sshd -d -p 2222, then connect with ssh -p 2222 user@remotehost.

share|improve this answer
add comment

debug1: Offering public key: /home/jsmith/.ssh/id_rsa

...

debug1: Trying private key: /home/jsmith/.ssh/id_dsa

It seems to me that private/public key merely do not match. Key names tell us that public key is RSA key and private key is DSA.

Try to generate a new pair and scp public key to server.

share|improve this answer
    
one can verify is this is actually the case by comparing the fingerprints of the two keys with ssh-keygen -l -f ~/.ssh/id_rsa' and ssh-keygen -l -f ~/.ssh/id_rsa.pub`. I don't believe that it would even offer the keys if there was a mismatch, however. I think its just that one is being rejected by the server for a not yet determined reason, so it tries another. –  stew Jan 9 '13 at 14:40
add comment

I experienced this sometime ago on RHEL5 (I dont know if this is the distro you are using), and found that it was only when I used ssh-copy-id. Try scp'ing the key file to the correct folder, and of course resetting the permissions

share|improve this answer
add comment

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.