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

Question

I added the public ssh key to the authorized_keys file. ssh localhost should log me in without asking for the password.

I did that and tried typing ssh localhost, but it still asks me to type in the password. Is there any other setting that I have to go through to make it work?

I have followed instruction for changing permissions:

Below is the result if I do ssh -v localhost

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Then it asks for passphase after the above log. Why isn't it logging me in without a password?

Answer 1

You need to verify the permissions of the authorized_keys file and the folder / parent folders in which it is located.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

For more information see this page.

You may also need to change/verify the permissions of your home directory to remove write access for the group and others.

chmod go-w ~

Answer 2

SELinux can also cause authorized_keys not to work. Especially for root in CentOS 6 and 7. No need to disable it though. Once you've verified your permissions are correct, you can fix this like so:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

Answer 3

setting ssh authorized_keys seem to be simple but hides some traps I'm trying to figure

-- SERVER --

in /etc/ssh/sshd_config set passwordAuthentication yes to let server temporary accept password authentication

-- CLIENT --

consider cygwin as linux emulation and install & run openssh

1. generate private and public keys (client side) # ssh-keygen

here pressing just ENTER you get DEFAULT 2 files "id_rsa" and "id_rsa.pub" in ~/.ssh/ but if you give a name_for_the_key the generated files are saved in your pwd

2. place the your_key.pub to target machine ssh-copy-id user_name@host_name

if you didn't create default key this is the first step to go wrong ... you should use

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. logging ssh user_name@host_name will work only for default id_rsa so here is 2nd trap for you need to ssh -i path/to/key_name user@host

(use ssh -v ... option to see what is happening)

If server still asks for password then you gave smth. to Enter passphrase: when you've created keys ( so it's normal)

if ssh is not listening default port 22 must use ssh -p port_nr

-- SERVER -----

4. modify /etc/ssh/sshd_config to have

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(uncoment if case)

This tells ssh to accept authorized_keys and look in user home directory for key_name sting written in .ssh/authorized_keys file

5 set permissions in target machine

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Also turn off pass auth

passwordAuthentication no

to close the gate to all ssh root/admin/....@your_domain attempts

6 ensure ownership and group ownership of all non-root home directories are appropriate.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user 

===============================================

7. consider the excelent http://www.fail2ban.org

8. extra ssh TUNNEL to access a MySQL (bind = 127.0.0.1) sever

Answer 4

Also be sure your home directory is not writeable by others

chmod g-w,o-w /home/USERNAME

Answer is stolen from here

Answer 5

the desperate may also make sure they don't have extra newlines in the authorized_keys file due to copying id_rsa.pub text out of a confused terminal.

Answer 6

Listing a public key in .ssh/authorized_keys is necessary but not sufficient for sshd (server) to accept it. If your private key is passphrase-protected, you'll need to give ssh (client) the passphrase every time. Or you can use ssh-agent, or a gnome equivalent.

Your UPDATE'd trace is consistent with a passphrase-protected private key. See ssh-agent, or ssh-keygen -p.

Answer 7

Beware that SELinux can trigger this error as well, even if all permissions seem to be OK. Disabling it did the trick for me (insert usual disclaimers about disabling it).

Answer 8

user is your username

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

Answer 9

The thing that did the trick for me finally was to make sure that the owner/group were not root but user:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

Answer 10

Write command:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

After you do this, make sure your dir is like that:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

Answer 11

Try "ssh-add" which worked for me.

Answer 12

Another tip to remember. Since v7.0 OpenSSH disables DSS/DSA ssh keys by default due to their inherit weakness. So if you have OpenSSH v7.0+, make sure your key is not ssh-dss.

If you are stuck with DSA keys, you can re-enable support locally by updating your sshd_config and ~/.ssh/config files with lines like so: PubkeyAcceptedKeyTypes=+ssh-dss

Answer 13

In my case I needed to put my authorized_keys file in .openssh.

This location is specified in /etc/ssh/sshd_config under the option AuthorizedKeysFile %h/.ssh/authorized_keys.

Answer 14

Make sure that the target user has a password set. Run passwd username to set one. This was required for me even if password SSH login was disabled.

Answer 15

this solves my problem

ssh-agent bash

ssh-add

Answer 16

Another issue you have to take care. If your generated file is not default id_rsa and id_rsa.pub

You have to create .ssh/config file and define manually which id file you are going to use with the connection.

Example is here:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

Answer 17

I issued sudo chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys and chmod go-w $HOME $HOME/.ssh from above and it fixed my problem on a CentOS7 box that I had messed up the permissions on while trying to get samba shares working. Thanks

Answer 18

It seems like a permission problem. Usually it happens if the permission of some file/directory is not correctly set up. In most case they are ~/.ssh and ~/.ssh/*. In my case they are /home/xxx.

You can changing the log level of sshd by modifying /etc/ssh/sshd_config(search LogLevel, set it to DEBUG), then check the output in /var/log/auth.log to see what happened exactly.

Answer 19

My problem was a modified AuthorizedKeysFile, when the automation to populate /etc/ssh/authorized_keys had not yet been run.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Answer 20

Just look on /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.

Answer 21

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

Answer 22

you need to verify the properties of the files. to assign the required property use:

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

Answer 23

on that note, make sure you sshd config has -;

PermitRootLogin without-password

set as the above, then restart sshd(/etc/init.d/sshd restart)

log-out and try log-in in again!

default I believe is -;

PermitRootLogin no

Answer 24

In my case it's because the user's group is not set in AllowGroups of config file /etc/ssh/sshd_config. After adding it everything works fine.

Answer 25

I have the home directory in a non-standard location and in sshd logs I have this line:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

even if all permissions were just fine (see the other answers).

I have found a solution here: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

In my particular case:

• added a new line in /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

  • this is the original line for regular home directories:

    /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

  • this is my new line:

    /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

• followed by a restorecon -r /data/ and a sshd restart

Answer 26

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

In my case, 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.

Answer 27

Look at /var/log/auth.log on the server for sshd auth errors.

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

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

Then connect from the 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 info I realized that my sshd_config was restricting logins to members of the ssh group. The following command fixed this permission error:

sudo usermod -a -G ssh NEW_USER

Answer 28

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 prompt worked again.