☰

带密钥的 SSH 连接不可靠

tag-icon • tag-icon ssh public-key
带密钥的 SSH 连接不可靠

我是一家小公司的实习系统管理员。遇到问题时，没有真正的系统管理员可以向我咨询。谢谢你的帮助

该公司使用 Nagios 来监控他们的网络服务器。他们使用 connect_by_ssh 来监控公钥和私钥。问题是它有时有效，有时无效。有人总是可以使用名称和密码登录。只是密钥并不总是有效。

为您提供一些日志：

Jan 16 13:23:10 localhost nagios3: SERVICE ALERT:
Server02;SSH;CRITICAL;SOFT;1;Connection timed out

Jan 16 13:24:10 localhost nagios3: SERVICE ALERT:
Server02;SSH;CRITICAL;SOFT;2;Connection timed out

Jan 16 13:24:50 localhost nagios3: SERVICE ALERT:
Server02;SSH;OK;SOFT;3;SSH OK - OpenSSH_5.3 (protocol 2.0)

Jan 16 14:15:10 localhost nagios3: SERVICE ALERT:
Server02;SSH;CRITICAL;SOFT;1;Connection timed out

Jan 16 14:15:50 localhost nagios3: SERVICE ALERT:
Server02;SSH;OK;SOFT;2;SSH OK - OpenSSH_5.3 (protocol 2.0)

确保万无一失，即使 ssh 使用用户/密码

nmap server02.8p-hosting.com

Starting Nmap 5.00 ( http://nmap.org ) at 2014-01-16 14:16 EST
Interesting ports on abc.domain.com (xxx.xxx.xxx.xxx):
Not shown: 971 closed ports
PORT     STATE    SERVICE
22/tcp   open     ssh

以下是一个正常星期的情况：

本周 ssh

会是什么呢？

日志/调试

ssh -vvv [email protected] OpenSSH_5.5p1 Debian-6+squeeze4, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to abc.domain.com [xxx.xxx.xxx.xxx] port 22. debug1: connect to address xxx.xxx.xxx.xxx port 22: Connection timed out ssh: connect to host abc.domain.com port 22: Connection timed out

答案1

这看起来更像是超时问题，而不是与 SSH 本身有关的问题。

看看你的 nagios 检查。

您可能想要向 check_by_ssh 添加 -t 选项：

 -t, --timeout=INTEGER
    Seconds before connection times out (default: 10)

您可能还应该检查service_check_timeout您的 nagios.cfg。

我的设置为60秒。

http://nagios.sourceforge.net/docs/nagioscore/3/en/configmain.html

答案2

不幸的是，它可能是由多种因素造成的，我要做的第一件事就是将 ssh 服务器上的 ssh 日志设置为“DEBUG”。

另外，我假设您的意思是他们正在使用 check_ssh 来监控盒子上的 ssh 服务器。在 nagios 内部，您可以做几件事来查看正在执行的确切命令。如果您有 nagios 服务器的 ssh 访问权限，您只需登录并查看 nagios services.cfg，即可准确找到正在调用的 nagios 插件以及确切的开关。

然后查看commands.cfg以查看正在执行的内容。然后尝试使用该命令从命令行手动测试ssh服务器。

另一种方法是使用 nagios 的界面。在左侧的导航栏上，底部有一个配置链接。单击它，然后使用下拉菜单转到服务，并准确找到该服务调用的插件。接下来使用下拉菜单转到命令扩展并以此方式获取命令。然后手动检查。

最后，查看是否启用了 SELinux，如果启用了，则可能需要更改文件的 selinux 上下文。如果您使用的是 puppet 或 chef 之类的程序，则可能正在争夺正在修复然后损坏的文件。等等。

更新：

我会尝试添加-E和/或-S到 check_by_ssh 命令。有时，如果它认为应该等待，奇怪的 ssh 输出可能会弄乱连接。此外，添加-v会告诉你发生了什么事。

答案3

我之前曾见过此问题，它是一个 DNS 问题。

也许 rDNS 查找超时（如上面的评论所述）或者服务器实际上是使用轮询 DNS（一个域名有多个 A 记录）并且只有一部分服务器处于离线状态、未运行 SSH 或以其他方式导致测试失败。

相关内容