Sign up ×
Server Fault is a question and answer site for 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 [] 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_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
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

5 Answers 5

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
Good answer. But for an SELinux newbie it would also be interesting to know how to inspect the list and inspect the permissions. – zrajm Mar 27 at 14:54

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
Thanks a lot for your wild guess (home directory is group writable). That was exactly my case. – skwllsp Apr 3 at 6:30
@skwllsp - please accept this answer if it is the correct one for your case. – Deer Hunter May 15 at 11:46
@Deer Hunter, The question has been asked by another person, not me. I can not accept this answer. – skwllsp May 15 at 12:33
@skwllsp - a senior moment from me, sorry. – Deer Hunter May 15 at 12:41

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

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/`. 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

I recommend to check authorities on ./ssh and user´s home directory, on key file and on authorized_keys file, as noone else then owner should be allowed to write and read there if you want ssh passwordless connection to work. That concerns both source and target machines. To be honest, sometimes it works even if there are bigger rights, but it should not.

share|improve this answer
Please check:… . Your post is also redundant, as you haven't read what others had written. – Deer Hunter May 15 at 11:49

Your Answer


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.