![带密钥的 SSH 连接不可靠](https://linux22.com/image/624800/%E5%B8%A6%E5%AF%86%E9%92%A5%E7%9A%84%20SSH%20%E8%BF%9E%E6%8E%A5%E4%B8%8D%E5%8F%AF%E9%9D%A0.png)
我是一家小公司的实习系统管理员。遇到问题时,没有真正的系统管理员可以向我咨询。谢谢你的帮助
该公司使用 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 -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 或以其他方式导致测试失败。