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

Question

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?

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 09 '13 at 14:46

Kenny Rasschaert · Answer 1 · 2013-01-09T14:47:22.773

21

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

edited Jan 09 '13 at 14:47

answered Jan 09 '13 at 14:41

Kenny Rasschaert

8,925
3
41
58

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
Thanks, you saved my day! However, for some reason, to make it work, I needed move keys to a new file named "authorized_keys2". – Imad Sep 22 '22 at 13:47

score 16 · Answer 2 · answered Jan 09 '13 at 14:42

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.

answered Jan 09 '13 at 14:42

stew

9,263
1
28
43

4

Thanks a lot for your wild guess (home directory is group writable). That was exactly my case. – Apr 03 '15 at 06:30
@skwllsp - please accept this answer if it is the correct one for your case. – Deer Hunter 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. – May 15 '15 at 12:33
@skwllsp - a senior moment from me, sorry. – Deer Hunter May 15 '15 at 12:41
chmod 744 to my home directory solved it - it was related to this answer, thanks! – Brandt Solovij Feb 09 '16 at 21:28
Old thread, but a life saver for me! – Aldo Sep 25 '20 at 19:11
nice, @Aldo I still use it all the time. happy hacking – stew Sep 26 '20 at 00:05

score 3 · Answer 3 · answered Feb 04 '16 at 16:29

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.

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. — Michael Scheper, Oct 19 '21 at 01:32

score 2 · Answer 4 · answered Jan 09 '13 at 14:31

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

answered Jan 09 '13 at 14:31

GeoSword

1,647
12
16

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. – Michael Scheper Oct 19 '21 at 01:43

score 1 · Answer 5 · answered Mar 13 '20 at 22:08

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

score 0 · Answer 6 · answered Nov 29 '18 at 15:42

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.

answered Nov 29 '18 at 15:42

helvete

141
5

score 0 · Answer 7 · answered Oct 23 '19 at 05:02

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:

How is SSH_AUTH_SOCK setup and used by ssh-agent?

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.

score -1 · Answer 8 · answered Jan 09 '13 at 14:35

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

answered Jan 09 '13 at 14:35

gevial

1,264
8
13

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 09 '13 at 14:40

score -2 · Answer 9 · answered May 15 '15 at 11:06

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

answered May 15 '15 at 11:06

alan

1

1

Please check: https://serverfault.com/questions/464411/trying-to-ssh-in-to-remote-computer-but-still-asking-for-password#comment835351_464420 . Your post is also redundant, as you haven't read what others had written. – Deer Hunter May 15 '15 at 11:49

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

9 Answers9