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?
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.
The following permissions are needed:
- The public key:
- The private key:
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 ~/
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.
Changing the permissions for the ~/.ssh folder solved my problem according to this post on Super User SE.
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.
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
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.
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
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)
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.
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:
... and add it to the remote's authorized_keys file in:
Another, in my case better solution was to add a custom host in my local ssh config file. On my Mac it is:
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: