Adding a public key to ~/.ssh/authorized_keys does not log me in automatically

Look in file /var/log/auth.log on the server for sshd authentication errors.

If all else fails, then run the sshd server in debug mode:

sudo /usr/sbin/sshd -ddd -p 2200

Then connect from the client:

ssh user@host -p 2200

In my case, I found the error section at the end:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

With this information I realized that my sshd_config file was restricting logins to members of the ssh group. The following command fixed this permission error:

sudo usermod -a -G ssh NEW_USER

Just look in file /var/log/auth.log on the server. Setting additional verbosity with -vv on the client side won't help, because the server is unlikely to offer too much information to a possible attacker.

Make sure you've copied the whole public key to authorized_keys; the ssh rsa prefix is necessary for the key to work.

You need to verify the properties of the files.

To assign the required property, use:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

I had this problem and none of the other answers solved it, although of course the other answers were correct.

In my case, it turned out that the /root directory itself (not e.g. /root/.ssh) had the wrong permissions. I needed:

chown root.root /root
chmod 700 /root

Of course, those permissions should be something like that (maybe chmod 770) regardless. However, it specifically prevented sshd from working, even though /root/.ssh and /root/.ssh/authorized_keys both had correct permissions and owners.

I had this problem when I added the group of the login user to another user.

Let's say there is an SSH-login user called userA and a non-SSH-login user userB. userA has the group userA as well. I modified userB to have the group userA as well. The lead to the the described behaviour, so that userA was not able to login without a prompt.

After I removed the group userA from userB, the login without a prompt worked again.

I use it this way.

cat ~/.ssh/id_rsa.pub| ssh user@remote-system 'umask 077; cat >>~/.ssh/authorized_keys'

I have had the same issues since before, but today I had to set up one new server. What I could learn in this time...

The basic process to allow authentication without a password is as follows:

1. On the server, validate if your home folder has the .ssh folder. If it doesn't exist, you can create it manually with a mkdir command and then to assign the correct permissions with chmod, or otherwise you could use the same utility, ssh-keygen, to create private/public keys, but on the server for your user. This process will create the required .ssh folder.

2. On the local machine you also need to create the private/public keys with the ssh-keygen utility.

3. You need to move your public key to file .ssh/authorized_keys to the server. To achieve this, you can use the ssh-copy-id utility, or you can do it manually using the cat and scp commands.

4. In the best of cases, this will allow connect to your server without a password.

OK, now the issues that I found today: first there are several key generation algorithms: rsa, dsa, ecdsa and ed25519 and there are many releases of OpenSSH (you can have one version on your local machine and an old version on your server):

Hint: Using ssh -v helps to see additional information when you are connecting to the server.

OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f 31 Mar 2020

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3

The error in my case today was that I was trying to use a key with a "newer" generation algorithm that was not supported by the installed version of OpenSSH on the server. When I had checked the supported algorithms, another error that I found was that the server was rejecting my algorithm:

debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes

After that, I had to change the algorithm of my key and then I could connect with the server successfully.

OpenSSH releases notes: Link

In this case, we'll move the root key to the example_user, which also disables the root user's SSH key access.

1. SSH to the instance as root.

2. Create the .ssh directory for example_user.

   # mkdir /home/example_user/.ssh

3. Move the root key to example_user's SSH directory.

   # mv /root/.ssh/authorized_keys /home/example_user/.ssh/

4. Change the ownership of the .ssh directory from root to example_user so OpenSSH can read it.

   # chown -R example_user:example_user /home/example_user/.ssh

Source - https://www.vultr.com/docs/using-your-ssh-key-to-login-to-non-root-users#Option_2__Move_the_root_SSH_Key_to_the_Non_root_User