为什么不通过使用authorized_keys的ssh自动登录?

Modified on: Sat, 20 Jul 2019 07:40:02 +0800

我创建了一个私有/公共dsa-keypair。我把公钥放在服务器上

~/.ssh/authorized_keys

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

作者:Magnar

最佳答案

虽然你的问题可能已经被其他问题解决了,但我已经锁定了自己没有足够的机器在注销之前没有验证sshd_config更改所以提出了下面的过程,可能对sshd配置的未来调试有用变化:

请勿断开活动的ssh连接,直到AFTER测试验证了行为符合您的预期为止。

一个。验证你认为sshd应该做什么

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

℃。启动一个详细的“测试”版本的服务器,您可以监控

d。开始一个详细的'测试'客户端连接,你可以监视


一个。验证你认为sshd应该做什么

查看sshd配置文件,不要使用如下所示的所有注释(假设sshd_config是正确的文件并在/ etc / ssh中)

  

$ grep -v“^#”/ etc / ssh / sshd_config | grep -v“^ $”

这只是清除了一些东西,所以我们验证了我们认为我们正在改变的东西(不一定是否正确。)

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

来自我正在使用的sshd的手册页,

  

-t测试模式。只检查配置文件的有效性和
              钥匙的理智。这对于可靠地更新sshd非常有用
              配置选项可能会改变。

其他变化可能会有更微妙的情况。例如,
在确定之前不要禁用密码验证
公钥验证工作正常。

℃。启动一个详细的“测试”版本的服务器,您可以监控

  

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

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

d。开始一个详细的'测试'客户端连接,你可以监视

以详细模式运行ssh客户端连接,以在屏幕上显示更多可能导致您更好地调试错误的信息。

  

$ ssh -vvv -p 9999 server-name

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

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

祝你好运

作者:samt

相关问答

添加新评论