20

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?

1
  • 5
    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. Jan 9 '13 at 14:46
19

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

1
  • 2
    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 '15 at 14:54
16

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.

7
  • 4
    Thanks a lot for your wild guess (home directory is group writable). That was exactly my case.
    – user123223
    Apr 3 '15 at 6:30
  • @skwllsp - please accept this answer if it is the correct one for your case. May 15 '15 at 11:46
  • 1
    @Deer Hunter, The question has been asked by another person, not me. I can not accept this answer.
    – user123223
    May 15 '15 at 12:33
  • @skwllsp - a senior moment from me, sorry. May 15 '15 at 12:41
  • chmod 744 to my home directory solved it - it was related to this answer, thanks! Feb 9 '16 at 21:28
3

The poster who referred to SElinux hit the nail on the head for my problem, I don't want to use selinux but had forgotten to disable it, and server came up with selinux enabled on boot.

ssh -v Debug helped. The key is accepted:

debug1: Found key in /var/lib/amanda/.ssh/known_hosts:19
debug1: ssh_rsa_verify: signature correct

And then I get the error

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

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

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


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

My fix was to switch off selinux with setenforce 0 and then disabling in /etc/selinux. Then ssh passwordless login worked for me.

1
  • I'm having the same problem and seeing similar errors. Can you say more about what selinux is, and where to set setenforce 0? I tried adding it to the end of /etc/selinux/semanage.conf, the only file in that directory locally, and it didn't make the error go away. I don't have the privs to edit it on the remote machine. Oct 19 at 1:32
2

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

1
  • Elaborating on this: I was reluctant to use ssh-copy-id because I wasn't familiar with it; I've always just copied files, and when it didn't work, try to debug it with ssh -v. But after half an hour of frustration, I thought what the hell, try using this utility instead. And then it just started working. I had to clear some unwanted keys from authorized_keys on my remote machine, but in the end it saved a lot of frustration. Sometimes the easy way really is better. 😏 Oct 19 at 1:43
1

The issue might be caused by SE-Linux labels having been changed, for example by the :Z or :z options for docker bind-mounts

Try running these:

chcon --recursive unconfined_u:object_r:user_home_dir_t:s0 ${HOME}
chcon --recursive unconfined_u:object_r:ssh_home_t:s0 ${HOME}/.ssh
0

In my case, the problem was in incorrect format of authorized_keys file.

There should be no newline in between the format definition (ssh-rss, ssh-dss, ..) and the public key itself.

0

I had trouble earlier with ssh and keyfiles. On that occasion, renaming my id key to "id_rsa" helped. Unfortunately I have different keys for different servers. So that approach has a limited usefulness. It might help as a one-off.

Secondly today I again have this error in only one XTerm session, and everything work great in 6 other xterm sessions to the same server/hose machine. So I compared my output from env in both sessions. I found this is the working session, which was absent in the non-working session:

SSH_AUTH_SOCK=/run/user/1001/keyring/ssh 

I pasted that assignment into the non-working session:

export SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
ssh  user@host
... Welcome ...

In other words that solution worked for me.

I did a little checking on the SSH_AUTH_SOCKET. From this answer:

the path of the unix file socket that the agent uses for communication with other processes

I guess this is essential for key resolution based on the result.

-1

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.

1
  • 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
-2

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.

1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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