Я системный администратор-стажер в небольшой компании. Там нет настоящего системного администратора, чтобы я мог спрашивать, когда у меня возникают проблемы. Спасибо за помощь
Компания использует 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 root@abc.domain.com 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
К сожалению, это может быть любое количество вещей, первое, что я сделаю, это включу регистрацию ssh на ssh-сервере на «DEBUG».
Кроме того, я предполагаю, что вы имеете в виду, что они используют check_ssh для мониторинга ssh-сервера на ящиках. Внутри nagios есть несколько вещей, которые вы можете сделать, чтобы увидеть, какая именно команда выполняется. Если у вас есть ssh-доступ к серверу nagios, вы можете просто войти в систему и посмотреть на nagios services.cfg, чтобы узнать, какой именно плагин nagios вызывается и с какими именно переключателями.
Затем посмотрите файл commands.cfg, чтобы узнать, что выполняется. Затем попробуйте использовать эту команду для проверки сервера ssh вручную из командной строки.
Другой способ - использовать интерфейс nagios. На панели навигации слева внизу находится ссылка на конфигурацию. Щелкните по нему, затем с помощью раскрывающегося списка перейдите к службам и найдите, какой именно плагин вызывается для этой службы. Затем используйте раскрывающееся меню goto command и получите команду таким образом. Потом вручную проверьте.
Наконец, посмотрите, включен ли SELinux, если да, вероятно, необходимо изменить контекст selinux в файле. Если вы используете что-то вроде puppet или chef, возможно, дело в том, что файл был исправлен, а затем сломан. И т.п.
ОБНОВИТЬ:
Я бы попробовал добавить -E и / или -S к команде check_by_ssh. Иногда странный вывод ssh может испортить соединение, если он думает, что должен ждать. Кроме того, добавив -v даст вам представление о том, что происходит.
Это больше похоже на проблему с тайм-аутом, чем на сам SSH.
Взгляните на свои чеки нагиос.
Вероятно, вы захотите добавить параметр -t в check_by_ssh:
-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
Я видел это раньше как проблему с DNS.
Возможно, время поиска rDNS истекло (как указано в комментариях выше) или, возможно, сервер на самом деле представляет собой несколько серверов, использующих циклический DNS (несколько записей A для одного доменного имени), и только часть серверов отключена, не работает по SSH или иным образом не проходит тест.