添加公钥到~/。ssh/authorized_keys不会自动记录我。

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

我将公共ssh密钥添加到authorized_keys文件。ssh localhost应该在不需要密码的情况下登录我。

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?

我这样做了，尝试输入ssh localhost，但是它仍然要求我输入密码。还有其他的设置需要我去完成吗?

I have followed instruction for changing permissions:

我已经遵循了更改权限的指令:

Below is the result if I do ssh -v localhost

下面是我使用ssh - vlocalhost的结果。

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?

然后它要求在上面的日志之后的passphase。为什么不给我输入密码?

24 个解决方案

#1

831

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

您需要验证authorized_keys文件和它所在的文件夹/父文件夹的权限。

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 ~

#2

121

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:

SELinux还可以导致authorized_keys不工作。特别是在CentOS 6和7中。但不需要禁用它。一旦您验证了您的权限是正确的，您可以这样修复:

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

#3

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

设置ssh authorized_keys似乎很简单，但是隐藏了一些我想要计算的陷阱。

-- SERVER --

——服务器

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

在/etc/ssh/sshd_config中设置passwordAuthentication，允许服务器临时接受密码身份验证。

-- CLIENT --

——客户端

consider cygwin as linux emulation and install & run openssh

将cygwin视为linux仿真和安装和运行openssh。

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

1。生成私有和公钥(客户端)# 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个文件“id_rsa”和“id_rsa”。在~ /酒吧”。ssh/但是如果您给一个name_for_the_key，生成的文件将保存在您的pwd中。

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

2。your_key。目标机器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

/ / key_name ssh-copy-id我路径。酒吧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

3所示。登录ssh user_name@host_name只适用于默认的id_rsa，所以这里是您需要ssh -i路径/to/key_name user@host的第二个陷阱。

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

(使用ssh - v…选择查看正在发生的事情)

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

如果服务器仍然要求密码，那么您就给了smth。输入密码:当你创建了密钥(这是正常的)

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

如果ssh不监听默认端口22，那么必须使用ssh -p port_nr。

-- SERVER -----

- - - - - - - - -服务器

4. modify /etc/ssh/sshd_config to have

4所示。修改/etc/ssh/sshd_config有

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

(uncoment if case)

(如果情况uncoment)

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

这告诉ssh接受authorized_keys，并查看在.ssh/authorized_keys文件中写入key_name的用户主目录。

5 set permissions in target machine

在目标机器上设置权限。

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

Also turn off pass auth

也要关掉通过auth。

passwordAuthentication no

passwordAuthentication没有

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

关闭所有ssh root / admin / ....门@your_domain尝试

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

7所示。考虑到优质的http://www.fail2ban.org

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

8。额外的ssh通道访问一个MySQL (bind = 127.0.0.1)服务器。

#4

Also be sure your home directory is not writeable by others

还要确保您的主目录不能被其他人写入。

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

Answer is stolen from here

答案在这里被偷走了。

#5

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.

在.ssh/authorized_keys中列出一个公钥是必要的，但对于sshd(服务器)接受它是不够的。如果您的私钥是passphrase-protected，您将需要每次都给ssh(客户端)的密码。或者您可以使用ssh-agent，或者gnome等效项。

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

您的更新跟踪与一个受保护的私有密钥是一致的。见ssh-agent，或ssh-keygen -p。

#6

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.

绝望的人可能还会确保他们在authorized_keys文件中没有额外的新行，因为要复制id_rsa。从混乱的终端发出的酒吧文本。

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

要注意，SELinux也可以触发这个错误，即使所有的权限看起来都是OK的。禁用它对我起了作用(插入通常的免责声明)。

#8

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

对我来说最关键的是要确保所有者/群体不是root用户，而是用户:

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

#9

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

#10

Try "ssh-add" which worked for me.

试试“ssh-add”，这对我很有效。

#11

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

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

另一个提示。因为v7.0 OpenSSH在默认情况下禁用DSS/DSA ssh密钥，因为它们继承了缺陷。因此，如果您有OpenSSH v7.0+，请确保您的密钥不是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

如果您使用DSA键，您可以通过更新sshd_config和~/来重新启用本地支持。ssh/config文件中有这样的行:PubkeyAcceptedKeyTypes=+ssh-dss。

#13

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.

确保目标用户有密码设置。运行passwd用户名设置一个。这对我来说是必需的，即使密码SSH登录是禁用的。

#14

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

在我的例子中，我需要将authorized_keys文件放在.openssh中。

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

这个位置是在/etc/ssh/sshd_config下指定的，选项授权keysfile %h/.ssh/authorized_keys。

#15

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

我发行了sudo chmod 700 ~/。ssh和chmod 600 ~/。ssh/authorized_keys和chmod $HOME $HOME/。来自上面的ssh，它将我的问题固定在一个CentOS7框上，我在尝试让samba共享工作时把权限弄乱了。谢谢

#16

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.

这似乎是一个权限问题。通常，如果某些文件/目录的权限设置不正确，则会发生这种情况。在大多数情况下他们是~/。ssh和~ / . ssh / *。在我的例子中，它们是/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.

您可以通过修改/etc/ssh/sshd_config(搜索日志级别，将其设置为DEBUG)来更改sshd的日志级别，然后检查/var/ log/auth。记录下到底发生了什么。

#17

this solves my problem

这解决了我的问题

ssh-agent bash

ssh-agent bash

ssh-add

ssh-add

#18

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

另一个问题是你要小心。如果生成的文件不是默认的id_rsa和id_rsa.pub。

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

您必须创建.ssh/config文件，并手动定义您将在连接中使用的id文件。

Example is here:

这里的例子是:

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

#19

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

确保您已经将整个公钥复制到authorized_keys;ssh rsa前缀是工作的关键。

#20

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

在这一点上，确保sshd配置有-;

PermitRootLogin without-password

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

设置为上述，然后重新启动sshd(/etc/init)。d / sshd重启)

log-out and try log-in in again!

退出登录，再次登录!

default I believe is -;

我认为是违约;

PermitRootLogin no

#21

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.

在我的例子中，这是因为用户组没有设置在配置文件/etc/ssh/sshd_config的AllowGroups中。添加后，一切正常。

#22

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

我的问题是一个经过修改的AuthorizedKeysFile，当自动化填充/etc/ssh/authorized_keys还没有运行时。

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

#23

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

我有一个非标准位置的主目录在sshd日志中有这一行

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

我在这里找到了一个解决方案:http://arstechnica.com/civis/viewtopic.php?

In my particular case:

我的具体情况:

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

在/etc/selinux/targeted/contexts/files/file_contexts中添加一条新行。
- this is the original line for regular home directories:
  
  这是普通家庭目录的原始线路:
  
  /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
  
  /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
  
  /数据/ home /[^ /]* / \ . ssh(/ . *)?unconfined_u:object_r:ssh_home_t:s0
followed by a restorecon -r /data/ and a sshd restart

然后是恢复-r /data/和sshd重启。

#24

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.

只是看/var/log/auth.登录服务器。在客户端设置额外的verbosity是没有用的，因为服务器不太可能向可能的攻击者提供过多的信息。

#1

831