28

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 'SO- stop being evil' Dec 2 '10 at 19:56

10 Answers 10

32

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 'SO- stop being evil' Dec 2 '10 at 19:59
  • 7
    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
9

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)

0

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.

0

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à

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.