25

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?

  • 1
    ​​serverfault.com/questions/208181/… I'm not sure what StackExchange policy on duplicates across sites is, but it doesn't seem to me that cross-posting a question would be helpful. – ephemient Dec 2 '10 at 7:04
  • If you've checked that only you can write to ~, ~/.ssh and ~/.ssh/authorized_keys, run ssh -vvv server.example.com and report the output (anonymize the host and user names if you want). If you have root access on the server, look at log entries created when you attempt a public key login. – Gilles Dec 2 '10 at 19:56
27

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.

  • 4
    Yup. ssh-copy-id should have taken care of the permissions of ~/.ssh and ~/.ssh/authorized_keys, but also make sure that your home directory itself isn't group-writable. – Gilles Dec 2 '10 at 19:59
  • 6
    This was it, for me. I used ssh-copy-id to send over an RSA key, and I was still getting prompted. Running chmod g-w homedir on the remote server worked like a charm. – Ben Kreeger Sep 28 '11 at 14:19
5

The following permissions are needed:

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

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.

1

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

0

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.

0

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.

0

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
  • I wouldn't call that message "very explicit". It tells you very vaguely what you should be looking for (incorrect ownerships and permissions), but does not tell you which directory or file to check, nor what the correct settings should be. – Urhixidur Sep 27 '17 at 14:22
0

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)

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.