1. 技术文章
  2. Adding public key to ~/.ssh/authorized_keys does not log me in automatically

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

由 霸气de小男生 提交于 2019-11-27 16:33:33
Teddy

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 ~

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
bortunac

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

Stephan Hoyer

Also be sure your home directory is not writeable by others

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

Answer is stolen from here

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.

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.

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).

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

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

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

Try "ssh-add" which worked for me.

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

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.

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.

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

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

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.

this solves my problem

ssh-agent bash

ssh-add

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.

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

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

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.

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

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

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.

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

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.

标签
ssh
public-key
authorized-keys
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!