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

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

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.

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

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