☰

为什么使用 authorized_keys 通过 ssh 自动登录不起作用？

tag-icon • tag-icon security ssh login
为什么使用 authorized_keys 通过 ssh 自动登录不起作用？

我已经创建了私钥/公钥对。我已将公钥放在服务器上

~/.ssh/authorized_keys

一切都像我的其他服务器一样设置，但似乎服务器只是忽略了我的努力。

答案1

虽然您的问题可能已经被其他答案解决，但是我已经将自己锁定在足够多的机器之外，因为在注销之前没有验证 sshd_config 更改，因此想出了下面的过程，这可能对将来调试 sshd 配置更改有用：

在测试验证行为符合预期之前，请勿断开活动的 ssh 连接。

a. 验证你认为 sshd 应该做什么

b. 使用“-t”验证配置是否有效

c. 启动一个可以实时监控的详细“测试”服务器版本

d. 启动一个可以实时监控的详细“测试”客户端连接

a. 验证你认为 sshd 应该做什么

使用类似下面的内容检查不带注释的 sshd 配置文件（假设 sshd_config 是正确的文件并且位于 /etc/ssh 中）

$ grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"

这只是清除了一些事情，以便我们验证我们认为正在改变的内容（不一定是正确的。）

b. 使用“-t”验证配置是否有效

从我正在使用的 sshd 的手册页来看，

-t 测试模式。仅检查配置文件的有效性和密钥的完整性。这对于可靠地更新 sshd 很有用，因为配置选项可能会发生变化。

其他更改可能会有更微妙的情况。例如，在确定公钥验证正常工作之前，请勿禁用密码验证。

c. 启动一个可以实时监控的详细“测试”服务器版本

$ sudo /usr/sbin/sshd -ddd -p 9999

这会使现有的工作会话保持活动状态，但会为您提供另一个 sshd 实例来验证新的配置更改。SSHD 现在在前台运行到用户定义的端口（在我们的示例中为 9999），并推送大量嘈杂的调试信息，您可以在 /var/log/authlog（或可能是 /var/log/auth.log，具体取决于您的操作系统）中跟踪这些信息。

d. 启动一个可以实时监控的详细“测试”客户端连接

以详细模式运行 ssh 客户端连接，以在屏幕上显示更多信息，从而帮助您更好地调试错误。

$ ssh -vvv -p 9999 服务器名称

现在，您应该在服务器的日志文件或客户端的连接屏幕中拥有足够的信息来隔离您的问题。

解决方案通常归结为文件权限（如 Magnar 和 setatakahashi 所示）

祝你好运

答案2

如果所有者属性错误，服务器将忽略您的 authorized_keys 文件。将其更改为以下内容可修复此问题：

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

答案3

$ chmod 700 ~

$ chmod 700 ~/.ssh

$ chmod 600 ~/.ssh/authorized_keys

检查 /etc/ssh/sshd_config 中的这些属性

$ sudo grep PubkeyAuthentication /etc/ssh/sshd_config

$ sudo grep 协议 /etc/ssh/sshd_config

答案4

另一个重要的陷阱......

如果你的主目录已加密sshd 将无法访问 ~/.ssh/authorized_keys。

看这回答

相关内容