向 ~/.ssh/authorized_keys 添加公钥不会让我自动登录

Posted 2023-02-23

【中文标题】向 ~/.ssh/authorized_keys 添加公钥不会让我自动登录

【英文标题】：Adding a public key to ~/.ssh/authorized_keys does not log me in automatically

【发布时间】：2011-09-16 15:32:34

【问题描述】：

我将公共 SSH 密钥添加到 authorized_keys 文件中。 ssh localhost 无需输入密码即可登录。

我这样做并尝试输入ssh localhost，但它仍然要求我输入密码。我必须通过其他设置才能使其正常工作吗？

我已按照说明更改权限：

如果我执行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>

然后它会在上述日志之后要求一个 passphase。为什么没有密码就不能登录？

【问题讨论】：

虽然这里不是这样，但如果您来自 Google 并且您使用的是加密的主目录，sshd 将无法访问它，因此不会能够读取您的 authorized_keys 文件。这是一个解决方案：bugs.launchpad.net/ubuntu/+source/openssh/+bug/362427/comments/…

【参考方案1】：

我之前也遇到过同样的问题，但今天我不得不设置一台新服务器。这段时间我能学到什么……

允许无密码认证的基本流程如下：

在服务器上，验证您的主文件夹是否有 .ssh 文件夹。如果它不存在，您可以使用mkdir 命令手动创建它，然后使用chmod 分配正确的权限，否则您可以使用相同的实用程序ssh-keygen 创建私钥/公钥，但在您的用户的服务器上。此过程将创建所需的.ssh 文件夹。

在本地机器上您还需要使用ssh-keygen 实用程序创建私钥/公钥。

您需要将您的公钥文件.ssh/authorized_keys 移动到服务器。为此，您可以使用ssh-copy-id 实用程序，也可以使用cat 和scp 命令手动完成。

在最好的情况下，这将允许在没有密码的情况下连接到您的服务器。

好的，现在我今天发现的问题：首先有几个密钥生成算法：rsa、dsa、ecdsa 和ed25519，并且 OpenSSH 有很多版本（你可以在您的本地计算机和服务器上的旧版本）：

提示：使用ssh -v 有助于在您连接到服务器时查看更多信息。

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

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

今天我的错误是我试图使用具有“较新”生成算法的密钥，而服务器上安装的 OpenSSH 版本不支持该密钥。当我检查了支持的算法时，我发现另一个错误是服务器拒绝了我的算法：

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

在那之后，我不得不改变我的密钥的算法，然后我才能成功连接到服务器。

OpenSSH 发布说明：Link

【参考方案2】：

当我将登录用户的组添加到另一个用户时，我遇到了这个问题。

假设有一个名为 userA 的 SSH 登录用户和一个非 SSH 登录用户 userB。 userA 也有组 userA。我修改了 userB 以拥有组 userA 。导致所描述的行为，因此 userA 在没有提示的情况下无法登录。

从 userB 中删除组 userA 后，没有提示的登录再次起作用。

【参考方案3】：

在服务器上的文件/var/log/auth.log 中查找sshd 身份验证错误。

如果一切都失败了，则在调试模式下运行sshd 服务器：

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

然后从客户端连接：

ssh user@host -p 2200

就我而言，我在最后发现了错误部分：

    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]

有了这些信息，我意识到我的sshd_config 文件将登录限制为ssh 组的成员。以下命令修复了此权限错误：

sudo usermod -a -G ssh NEW_USER

【讨论】：

这个额外的日志记录非常有用，谢谢！它显示我的一个密钥（复制并粘贴到 authorized_keys 中）中间有一个换行符！

【参考方案4】：

我遇到了这个问题，其他答案都没有解决它，尽管其他答案当然 是正确的。

在我的例子中，/root 目录本身（而不是 /root/.ssh）具有错误的权限。我需要：

chown root.root /root
chmod 700 /root

当然，无论如何，这些权限都应该是这样的（可能是chmod 770）。但是，它特别阻止了 sshd 工作，即使 /root/.ssh 和 /root/.ssh/authorized_keys 都具有正确的权限和所有者。

【参考方案5】：

您需要验证文件的属性。

要分配所需的属性，请使用：

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

【参考方案6】：

只需查看服务器上的文件/var/log/auth.log。在客户端使用 -vv 设置额外的详细信息无济于事，因为服务器不太可能向可能的攻击者提供太多信息。

【参考方案7】：

您必须注意的另一个问题：如果您生成的文件名不是默认的id_rsa 和id_rsa.pub。

您必须创建 .ssh/config 文件并手动定义要用于连接的 id 文件。

这里有一个例子：

Host remote_host_name
    HostName 172.xx.xx.xx
    User my_user
    IdentityFile /home/my_user/.ssh/my_user_custom

【讨论】：

IdentityFile 应该是私钥

@KenH 是的，当然。错字了。对此感到抱歉。

【参考方案8】：

我的主目录位于非标准位置，并且在 sshd 日志中我有以下行，即使所有权限都很好（请参阅其他答案）：

无法打开授权密钥“/data/home/user1/.ssh/authorized_keys”：权限被拒绝

我在这里找到了解决方案：Trouble with ssh public key authentication to RHEL 6.5

在我的特殊情况下：

在/etc/selinux/targeted/contexts/files/file_contexts.homedirs中添加了一个新行：

这是常规主目录的原始行：

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

这是我的新线路：

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

随后是 restorecon -r /data/ 和 sshd 重新启动。

【参考方案9】：

另一个要记住的提示：自 v7.0 OpenSSH disables DSS/DSA SSH keys by default 以来，由于它们的继承弱点。因此，如果您有 OpenSSH v7.0+，请确保您的密钥不是 ssh-dss。

如果您无法使用 DSA 密钥，您可以通过以下方式在本地重新启用支持 使用如下行更新您的 sshd_config 和 ~/.ssh/config 文件：PubkeyAcceptedKeyTypes=+ssh-dss

【参考方案10】：

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

【参考方案11】：

在下面，user 是您的用户名。

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

【讨论】：

更适合root：mkdir -p /home/$USER/.ssh && chown -R $USER:$USER /home/$USER/.ssh && sudo -u $USER ssh-keygen -t rsa && touch /home/$USER/.ssh/authorized_keys && touch /home/$USER/.ssh/known_hosts && 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 && vim /home/$USER/.ssh/authorized_keys # paste keys here!

【参考方案12】：

这解决了我的问题：

ssh-agent bash

ssh-add

【讨论】：

请解释一下这是做什么的。

ssh-agent 存储您的 ssh 密钥。命令 bash 启动其 shell 的新实例。和 ssh-add 解锁您的密钥并加载它们

【参考方案13】：

这似乎是一个权限问题。如果某些文件/目录的权限设置不正确，通常会发生这种情况。大多数情况下，它们是~/.ssh 和~/.ssh/*。就我而言，他们是/home/xxx。

您可以通过修改文件/etc/ssh/sshd_config（搜索LogLevel，并将其设置为DEBUG）来更改sshd的日志级别，然后检查文件/var/log/auth.log中的输出为看看到底发生了什么。

【讨论】：

这看起来与接受的答案基本相同，可能应该是对它的评论，而不是答案。多一点代表，you will be able to post comments。在此之前，请不要使用答案作为解决方法。

对不起，我认为这是解决各种问题的方法。现在我知道该怎么做了，谢谢。

【参考方案14】：

我从先前的答案中发出了sudo chmod 700 ~/.ssh 和chmod 600 ~/.ssh/authorized_keys 和chmod go-w $HOME $HOME/.ssh，它解决了我在CentOS 7 框上的问题，我在尝试让Samba 共享工作时弄乱了权限。

【参考方案15】：

请注意，确保您的 sshd 配置包含以下行：

PermitRootLogin without-password

如上设置，然后重启sshd (/etc/init.d/sshd restart)。

退出并尝试重新登录！

我相信默认是：

PermitRootLogin no

【参考方案16】：

最后对我有用的是确保所有者/组不是root，而是用户：

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

【讨论】：

chown：无效用户：'/home/lsa/.ssh/'

@Stepan Yakovenko：“用户”不是文字（？）。改进的答案可以使这一点更清楚。

【参考方案17】：

绝望的人还可以确保他们在 authorized_keys 文件中没有额外的换行符，因为他们从一个混乱的终端中复制了文件 id_rsa.pub 的文本。

【讨论】：

这正是发生在我身上的事！两个终端的宽度相同，因此很难弄清楚，直到我打开行号以查看 authorized_keys 文件中的两行。

这个。因为这个，我只是浪费了一个小时。这不是第一次。 @bortunac 的回答提到了 ssh-copy-id 工具，我将来会使用它来避免这种情况。

我使用more而不是cat获得了id_rsa.pub的内容，由于不可见的换行符，这是致命的。

【参考方案18】：

设置 ssh authorized_keys 似乎很简单，但它隐藏了一些我试图弄清楚的陷阱。

-- 服务器--

在/etc/ssh/sshd_config中，设置passwordAuthentication yes让服务器暂时接受密码认证

-- 客户--

将Cygwin 视为Linux 仿真并安装和运行OpenSSH

1. 生成私钥和公钥（客户端） # ssh-keygen

这里只需按Enter，您会得到默认两个文件，“id_rsa”和“id_rsa.pub "，在 ~/.ssh/ 中，但如果您提供 name_for_the_key，则生成的文件将保存在您的当前工作目录中。 p>

2.将your_key.pub文件传输到目标机器ssh-copy-id user_name@host_name

如果您没有创建默认密钥，这是出错的第一步 ...你应该使用：

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

3. 记录ssh user_name@host_name 仅适用于默认的id_rsa 文件，因此这是第二个陷阱。你需要做ssh -i path/to/key_name user@host

（使用 ssh -v ... 选项查看发生了什么。）

如果服务器仍然要求输入密码，那么你提供了一些东西。要输入密码：在您创建密钥后（这很正常）。

如果 ssh 未在默认端口 22 上侦听，则必须使用 ssh -p port_nr。

-- 服务器 -----

4.修改文件/etc/ssh/sshd_config有

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

（如果大小写，请取消注释）

这告诉 ssh 接受文件 authorized_keys 并在用户主目录中查找 .ssh/authorized_keys 文件中写入的 key_name 字符串.

5在目标机器上设置权限

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

同时关闭通过身份验证，

passwordAuthentication no

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

6.确保所有非根主目录的所有权和组所有权是适当的。

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

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

7.考虑一下优秀的http://www.fail2ban.org

8. 额外 SSH tunnel 访问 mysql (bind = 127.0.0.1) 服务器

【讨论】：

请注意，“just 4 security”不仅仅是为了安全！如果文件没有限制性权限，SSH 将忽略该文件。

确保所有权将是此列表的重要补充

我不知道ssh-copy-id！仅这一步就可以做出很好的回答。

chmod 755 ~/.ssh 而不是我在其他地方看到的 700 似乎可以做到这一点

哇...我的问题是“默认命名”（第 2 步）。 SSH 不拾取“.ssh”中的任何文件？这花了我几天的时间......非常感谢！

【参考方案19】：

在命令行上发出这些：

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

完成此操作后，请确保您的目录是这样的：

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

【讨论】：

您的答案与接受的答案有何不同？三年后你用你的 Ctrl+C Ctrl-V 命令写的？

【参考方案20】：

还要确保你的主目录不能被其他人写：

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

这个答案是从here偷来的。

【讨论】：

做chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys ; chmod g-w,o-w ~ 为我工作。谢谢。

为什么不改用chmod og-w /home/USERNAME？

【参考方案21】：

SELinux 也可能导致 authorized_keys 不起作用。尤其是CentOS 6 和 7 中的 root。不过没有任何必要禁用它。

一旦您验证了您的权限是正确的，您可以像这样解决这个问题：

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

【讨论】：

restorecon 是您手动复制文件后所需要的，例如到新硬盘。 （在这种情况下，您可能应该在所有文件上运行它。可以解决其他奇怪的问题。）

这里又是一个快乐的露营者。这是我在 RHEL 6.5 中的问题

9/10 次，“为什么这不起作用，它总是起作用”问题是 selinux 问题。

为我解决了 1and1 (1und1) 服务器上的问题

在 Fedora 35 上为我修复了迁移到另一个硬盘时的问题

【参考方案22】：

请注意SELinux 也会触发此错误，即使所有权限似乎都正常。禁用它对我有用（插入关于禁用它的常用免责声明）。

【讨论】：

你可以看到 SELinux 干扰了/var/log/audit/audit.log。 restorecon -R -v /root/.ssh 修复了我的具体情况。

【参考方案23】：

我就是这样用的。

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

【讨论】：

解释一下。

【参考方案24】：

在 .ssh/authorized_keys 中列出公钥是必要的，但不足以让 sshd（服务器）接受它。如果您的私钥受密码保护，则每次都需要向 ssh（客户端）提供密码。或者您可以使用 ssh-agent 或 GNOME 等价物。

您的更新跟踪与受密码保护的私钥一致。请参阅 ssh-agent，或使用 ssh-keygen -p。

【参考方案25】：

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

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

欲了解更多信息，请参阅this page。

您可能还需要更改/验证主目录的权限，以删除组和其他人的写入权限。

chmod go-w ~

【讨论】：

上面的一些东西奏效了，虽然“chmod -R go-wrx foobar”不是很戏剧化吗？为什么需要递归？

对于第二部分，不需要递归，只需执行chmod go-wrx foobar 就足够了。如果您对文件有某些组或其他访问权限，则递归执行此操作可能会严重影响某些应用程序，特别是如果它是一个 Web 目录。

正如 OpenSSH FAQ 中提到的，用户的 home 和 .ssh 目录只需要删除 group/other 的写权限（所以chmod go-w $HOME $HOME/.ssh 可以解决问题）。因此，如果您愿意，两个目录的权限都可以像 755 一样“开放”。最简单/侵入性最小的命令在常见问题解答中：openssh.org/faq.html#3.14

为什么直到我做了chmod 700 ~/.ssh && chmod 644 ~/.ssh/authorized_keys 才对我有用？ 600 没有在 644 的地方工作......

我还需要sudo chown -R $USER:$USER ~/.ssh/，因为我已将authorized_keys 文件作为root 编写。

【参考方案26】：

确保您已将整个公钥复制到authorized_keys； ssh rsa 前缀是密钥工作所必需的。

【讨论】：

使用的 ssh-copy-id

【参考方案27】：

就我而言，我需要将我的authorized_keys 文件放入.openssh。

此位置在/etc/ssh/sshd_config 选项AuthorizedKeysFile %h/.ssh/authorized_keys 下指定。

【讨论】：

服务器上可能会出现一整类问题（尝试从客户端连接时），如果不访问服务器就无法调试...这是为了隐藏信息而设计的恶意客户端，但更难调试。

【参考方案28】：

我的问题是修改了 AuthorizedKeysFile，而自动填充 /etc/ssh/authorized_keys 尚未运行。

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

【参考方案29】：

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

【参考方案30】：

试试对我有用的“ssh-add”。