ssh prompts for password despite ssh-copy-id

Question

I've been using public key authentication on a remote server for some time now for remote shell use as well as for sshfs mounts. After forcing a umount of my sshfs directory, I noticed that ssh began to prompt me for a password. I tried purging the remote .ssh/authorized_keys from any mention the local machine, and I cleaned the local machine from references to the remote machine. I then repeated my ssh-copy-id, it prompted me for a password, and returned normally. But lo and behold, when I ssh to the remote server I am still prompted for a password. I'm a little confused as to what the issue could be, any suggestions?

Answer 1

sshd gets weird about permissions on $HOME, $HOME/.ssh (both directories) and on $HOME/.ssh/authorized_keys.

One of my linux boxes ended up with drwxrwxrwx permissions on my $HOME directory. An Arch linux box absolutely would not log in using public keys until I removed 'w' permission for group, other on my $HOME directory.

Try making $HOME and $HOME/.ssh/ have more restrictive permissions for group and other. See if that doesn't let sshd do its stuff.

Answer 2

The following permissions are needed:

• The .ssh folder: 700 (drwx------)
• The public key: 644 (-rw-r--r--)
• The private key: 600 (-rw-------)

Answer 3

I recently experienced this issue as well.

It was corrected by modifying the permissions of the $HOME directory. However, simply running chmod g-w ~/ did not correct the issue. In addition to chmod g-w ~/ I also needed to modify the permissions of others on the $HOME directory by running chmod o-wx ~/

Together:

chmod g-w ~/
chmod o-wx ~/

Do note that I am not sure if o-x was necessary, I simply ran it as a precaution.

Answer 4

As this questions appears among the first search results when googling for this behaviour, I will also add my solution:

In my case it was nothing related to the permissions. For any reason (didn't bother myself to find out for which reason actually, as I found a quick fix) when executing the ssh command the program didn't look for the right identity file. One solution was to add manually on the remote server an SSH key which the SSH program tried to use. You can observe what the SSH program does when executing the command by adding -v to the command:

ssh -v username@your-host-ip-or-domain 

Then you just grab on your local machine any public key for which the SSH program tries find an identity file / private key for, on a Mac for example:

cat ~/.ssh/id_rsa.pub

... and add it to the remote's authorized_keys file in:

~/.ssh/authorized_keys

Another, in my case better solution was to add a custom host in my local ssh config file. On my Mac it is:

/Users/my-user-name/.ssh/config

Here you can add for example something like this:

Host mynewserver
        HostName some.IP.number.or.domain
        Port 20000 #if custom port is used and not the default 22
        User the_root
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_for_my_new_server

Then you just need to execute:

ssh mynewserver

...and Voilà

Answer 5

If your permission settings are correct, you may want to try to add the private key to your ssh agent:

1. Start ssh-agent if not started:

   eval $(ssh-agent)
   

2. Add your private key to the ssh agent using ssh-add(replace id_rsa_key with the name of your private key):

   ssh-add ~/.ssh/id_rsa_key  
   

3. Try to ssh to your remote server.

Answer 6

Changing the permissions for the ~/.ssh folder solved my problem according to this post on Super User SE.

Answer 7

Like other contributors mentionned, this is probably a permission issue.

The best way diagnose this is to restart the SSH daemon on the remote server with the debug option on - usually the "-d" option. The OpenSSH daemon message are very explicit. For example, you will see messages such as:

Authentication refused: bad ownership or modes for directory /some/path

Answer 8

Another possible problem is that the server does not support your key algorithm. In my case, I found the following messages in my sshd logs (/var/log/auth.log in my case):

userauth_pubkey: unsupported public key algorithm: ssh-ed25519 [preauth]

If that is the case, you either need to enable support for that algorithm in your sshd configuration (which might require an update to a more recent sshd version) or you need to switch your key to an algorithm supported by the sshd you're trying to connect to.

Answer 9

Another reason could be

debug1: send_pubkey_test: no mutual signature algorithm

(taken from ssh -vvv ...)

And solution is to add to yours ~/.ssh/config these lines:

HostKeyAlgorithms ssh-rsa
PubkeyAcceptedKeyTypes ssh-rsa

(it can be set in global scope working as a default fo all entries)

Answer 10

Does the problem occur also on parallel logins, i.e. if you try to mount sshfs while having an open ssh session? If not, then I would guess that you have your home directory encrypted? In this case $HOME/.ssh/authorized_keys would only become usable on the remote machine after your first login (using your password).

Check out https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting for an explanation and the required workaround.

Answer 11

I would post this as a comment, but it would probably be too long. I just wanted to add that ssh-copy-id tries to send the public key from the /.ssh location inside your $HOME folder.

If you are trying to ssh as root with a public key (save the security-related comments), ssh-copy-id could be trying to login with the wrong public key if your $HOME variable is set to anything other than /root (such as being set to your normal user's home directory), thus the root user would be getting prompted because root's public key is not installed on the remote system.

You can use the following one-liner to specify the exact public key:

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh user@remotehost "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

I have encountered this scenario in the wild a few times (including this morning) and figured I would try to put in my 2 cents, just in case anyone found themselves in the same situation.

Answer 12

The reason the public key was not surviving post reboot was that my server home directory was encrypted. (you do this while installing the server)

Answer 13

In my case at the remote server the following file:

/etc/ssh/sshd_config

had the following property set to no:

PubkeyAuthentication no

commenting it with a hash:

#PubkeyAuthentication no

did half the trick, the rest was to restart the ssh service:

/etc/init.d/sshd restart

Source: After ssh-copy-id, still need to provide password

Answer 14

I tried ssh from "client" to "target", playing with the "w" permission on group of ~/.ssh folder.

Do note that the same applies when you change the "w" permission of ~/.ssh/authorized_keys file.

Try "w" permission on other, you will see the same results.

The permission settings of id_rsa and id_rsa.pub files does not effect the password prompt during ssh login.

[root@target ~]# ls -al .ssh
total 12
drwx------. 2 root root   61 Jun  4 15:42 .
dr-xr-x---. 5 root root  178 Jun  4 02:45 ..
-rw-------. 1 root root  399 Jun  4 02:45 authorized_keys
-rwxrwxrwx. 1 root root 1675 Jun  4 15:42 id_rsa
-rwxrwxrwx. 1 root root  392 Jun  4 15:42 id_rsa.pub
[root@target ~]# exit
logout
Connection to 192.168.1.125 closed.
[root@client ~]# ssh 192.168.1.125              # NO PASSWORD PROMPT
Last login: Thu Jun  4 15:56:40 2020 from bkftlp
[root@target ~]# 
[root@target ~]# chmod g+w .ssh
[root@target ~]# ls -al .ssh
total 12
drwx-w----. 2 root root   61 Jun  4 15:42 .
dr-xr-x---. 5 root root  178 Jun  4 02:45 ..
-rw-------. 1 root root  399 Jun  4 02:45 authorized_keys
-rwxrwxrwx. 1 root root 1675 Jun  4 15:42 id_rsa
-rwxrwxrwx. 1 root root  392 Jun  4 15:42 id_rsa.pub
[root@target ~]# exit
logout
Connection to 192.168.1.125 closed.
[root@client ~]# ssh 192.168.1.125              # PASSWORD PROMPT
[email protected]'s password: 
Last login: Thu Jun  4 15:56:58 2020 from bkftlp
[root@target ~]# 
[root@target ~]# chmod g-w .ssh
[root@target ~]# ls -al .ssh
total 12
drwx------. 2 root root   61 Jun  4 15:42 .
dr-xr-x---. 5 root root  178 Jun  4 02:45 ..
-rw-------. 1 root root  399 Jun  4 02:45 authorized_keys
-rwxrwxrwx. 1 root root 1675 Jun  4 15:42 id_rsa
-rwxrwxrwx. 1 root root  392 Jun  4 15:42 id_rsa.pub
[root@target ~]# exit
logout
Connection to 192.168.1.125 closed.
[root@client ~]# ssh 192.168.1.125              # NO PASSWORD PROMPT
Last login: Thu Jun  4 15:57:43 2020 from bkftlp
[root@target ~]# 

    Next, remove all the permissions of id_rsa and id_rsa.pub files 

[root@target ~]# 
[root@target ~]# chmod 000 .ssh/id*
[root@target ~]# exit
logout
Connection to 192.168.1.125 closed.
[root@client ~]# ssh 192.168.1.125              # NO PASSWORD PROMPT
Last login: Thu Jun  4 16:17:56 2020 from bkftlp
[root@target ~]# ls -la .ssh
total 12
drwx------. 2 root root   61 Jun  4 15:42 .
dr-xr-x---. 5 root root  178 Jun  4 02:45 ..
-rw-------. 1 root root  399 Jun  4 02:45 authorized_keys
----------. 1 root root 1675 Jun  4 15:42 id_rsa
----------. 1 root root  392 Jun  4 15:42 id_rsa.pub
[root@target ~]#

Answer 15

Had to enable debug mode as suggested by @gerard lapeche and found the problem to be bad permissions on /root on the remote server. Ran this on the remote server:

chmod -R 700 /root

Answer 16

If you have verified all your permissions are correct, but are still being prompted for a password, make sure to add the below line to the file /etc/ssh/sshd_config on the system you want to login to without a password

pubkeyacceptedkeytypes ssh-rsa

After doing this, simply run the command service sshd restart and passwordless login should work now

Answer 17

Another thing to watch out is that you the "user" on THE REMOTE MACHINE (the one you are trying to connect to via ssh) actually owns the home directory:

Example:

$ ls -la /home
total 36
drwxr-xr-x  6 pedro  1000  4096 Jan  4  2017 .
drwxr-xr-x 22 root  root   4096 Mar 18  2016 ..
drwxr-xr-x  2 root  root   4096 Sep 24  2015 home
drwx------  2 root  root  16384 Apr  8  2016 lost+found
drwxr-xr-x 25  1000  1000  4096 Nov 19 02:30 pedro

The owner is ID:1000 for both "owner" and "group"

The SSH will prompt for password is ssh [email protected] is used

Lets correct it, lets use "chown"

$ sudo chown pedro /home/pedro

lets check :

$ ls -la /home
total 36
drwxr-xr-x  6 pedro  1000  4096 Jan  4  2017 .
drwxr-xr-x 22 root  root   4096 Mar 18  2016 ..
drwxr-xr-x  2 root  root   4096 Sep 24  2015 home
drwx------  2 root  root  16384 Apr  8  2016 lost+found
drwxr-xr-x 25 pedro  1000  4096 Nov 19 02:30 pedro

Group is still 1000 but user is "pedro"!

After this no password is needed:

$ ssh 192.168.1.81

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Nov 19 02:32:29 2022 from 192.168.1.95

Hope this helps

Answer 18

Ran into this issue while connecting to a server after upgrading to Ventura in MacOS.

Ventura ships with OpenSSH_9.0p1 which disables RSA signatures on SHA-1

The best solution would be to upgrade the remote server so it supports SHA-2

---

If that is not an option, you can generate a new key with a stronger algorithm

ssh-keygen -t ecdsa -b 521

And then ssh-copy-id with this new key

ssh-copy-id user@hostname -i /path/to/user/.ssh/id_ecdsa

If necessary remove the old key on your remote server ~/.ssh/authorized_keys

---

A third but not recommended option would be to enable SHA1 modifying /etc/ssh_config in your client by adding

PubkeyAcceptedKeyTypes +ssh-rsa

Answer 19

What worked for me: backup home directory then recreate it by using the below command.

mkhomedir_helper

Run the ssh-copy command and test again.