Основа / Проверка Nagios check_by_ssh возвращает Удаленное выполнение команды не удалось

Я использую Groundwork / Nagios и пытаюсь настроить check_by_ssh. Сейчас команда такая:

$USER1$/check_by_ssh -i ~nagios/.ssh/id_dsa -H $HOSTADDRESS$ -t 60 -l "$USER24$" -C "/tmp/test"

где /tmp/test — это программа Hello World.

но он возвращает сообщение "Remote command execution failed:********************************************"

У меня есть ключи ssh, настроенные для nagios, чтобы войти в $HOSTADDRESS$ как $USER24$, но я все еще получаю сообщение об ошибке. (Закрытый ключ находится в ~nagios/.ssh на базовой машине, а открытый ключ — в ~/$USER24$/.ssh на удаленном хосте)

Таким образом, check_by_ssh не может запустить какую-либо программу.


person Connor    schedule 21.06.2011    source источник


Ответы (9)


По какой-то причине добавление флага «-E» исправило это. Согласно справочной странице check_by_ssh, это флаг игнорирования STDERR. Теперь я получаю вывод из /tmp/test.

Финальная команда:

$USER1$/check_by_ssh -i ~nagios/.ssh/id_dsa -H $HOSTADDRESS$

-t 60 -l "$USER24$" -C "/tmp/test" -E

Окончательный вывод:

Привет, мир

person Connor    schedule 22.06.2011
comment
Это сработало и для меня; в моем конкретном случае я оборачиваю check_by_ssh с sshpass (досадная необходимость из-за того, что хостинг не разрешает ключевые файлы для доступа по SSH) - person STW; 24.01.2014

Если check_by_ssh не работает из-за того, что вам необходимо проверить подлинность ключа, вы можете отключить строгую проверку ключа хоста в параметрах check_by_ssh так же, как вы можете сделать это с клиентом ssh. Это небольшая жертва безопасности, но если вы находитесь в надежной частной сети, компромисс незначителен, и вам никогда не нужно подтверждать, что вы хотите продолжить подключение, даже с первой попытки:

/usr/lib/nagios/plugins/check_by_ssh -l nagios -o StrictHostKeyChecking=no
person Dave Stern    schedule 28.11.2012
comment
Это, очевидно, немного снижает вашу безопасность, лучшим вариантом может быть просто очистка вашего файла known_hosts на сервере icinga/nagios. - person Martin W; 19.02.2020

В моем случае ошибка возникла из-за обновления открытого ключа службы ssh, до которого дошел nagios.

На компьютере мониторинга, где установлен nagios, обновите или удалите файл «/var/spool/nagios/.ssh/known_hosts», чтобы удалить весь открытый ключ.

и попробуйте снова проверить check_by_ssh.

Пример :

# ./check_by_ssh -H target_machine -C "/bin/ls" 
Remote command execution failed: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

# rm /var/spool/nagios/.ssh/known_hosts

#  ./check_by_ssh -H target_machine -C "/bin/ls /" 
bin
boot
cgroup
core
data
dev
etc
home
...
person Cyrus31    schedule 27.06.2013

Просто столкнулся с этим на некоторых из моих систем. Я не мог понять это, но флаг -E помог. Причина, по которой это происходило на моих хостах, заключается в том, что я включил баннер SSH для отображения стандартного «Несанкционированное использование запрещено законом и бла-бла-бла». Этот баннер отображается через stderr, поэтому каждый из вызовов check_by_ssh завершился с ошибкой «Удаленное выполнение команды не удалось».

Так что, если ключи хоста не являются вашей проблемой, и вы недовольны -E, бросьте свой баннер. Если вы используете постоянное имя пользователя для своих проверок Nagios, вы можете исключить пользователя nagios из отображения баннера, используя параметр Match в sshd_config:

https://unix.stackexchange.com/questions/96975/disable-ssh-banner-for-specific-users-or-ips

person modea    schedule 03.03.2015

Вы должны вручную запустить команду в первый раз, потому что она задает вопрос, на который вы должны ответить «да». После этого он больше не требует взаимодействия.

Вы должны сделать это для каждого сервера, к которому вы подключаетесь.

person fred    schedule 07.08.2012
comment
Этот ответ правильный. Вам не нужно указывать ключ, если вы знаете, какой пользователь запускает команду, и ваш ключ находится в расположении по умолчанию (например, если пользователем является nagios и вы используете ключ rsa, ~nagios/.ssh/id_rsa ). - person Peter; 04.10.2012

Я нашел ответ.

Чтобы пропустить баннер, добавьте файл «config» в каталог .ssh на сервере nagios.

конфигурация кошки LogLevel=QUIET

chmod 600 конфиг

после этого баннер будет пропущен и проверка nagios будет работать без флага -E

С уважением Богдан

person Bogdan    schedule 01.06.2015

Если вы настроили открытый ключ, вам нужно передать ключ в своей команде SSH, например:

command_line    $USER1$/check_by_ssh -i /usr/local/nagios/etc/keys/$HOSTNAME$ -H $HOSTADDRESS$ -t 60 -l "$USER24$" -C "cd tmp"

Убедитесь, что открытый ключ имеет разрешение 0600.

person Rakesh Sankar    schedule 22.06.2011
comment
Я пробовал это, но я все еще получаю сообщение об ошибке. Я добавил некоторую информацию к моему вопросу. - person Connor; 22.06.2011
comment
@Коннор, ты пытался вручную запустить это ??? нравится: check_by_ssh -i /path/to/private-key -h 192.168.1.1 -u username - person Rakesh Sankar; 22.06.2011

У меня была такая же проблема с check_by_ssh на Icinga 2.

Я исправил это, установив vars.by_ssh_quiet = "true" в объекте команды (ссылка на документ Icinga 2).

object CheckCommand "by_ssh_redis" {
  import "by_ssh"
  vars.by_ssh_command = [ "/usr/lib64/nagios/plugins/check_redis.pl", "-H", "localhost"]
  vars.by_ssh_quiet  = "true"
}
person Sumesh    schedule 14.05.2016

В моем случае это произошло после того, как один из наших серверов был перестроен. Проблема заключалась в том, что в файле known_hosts на мастере icinga все еще был ключ SSH целевого хоста до того, как он был перестроен. Решение состояло в том, чтобы просто отредактировать файл known_hosts и удалить строку, относящуюся к целевому хосту. Для меня это было расположено в: /var/spool/icinga2/.ssh/known_hosts

После того, как вы сделаете это и запустите проверку, в первый раз вы, вероятно, увидите сообщение вроде:

Ошибка удаленного выполнения команды: Предупреждение: '172.16.0.90' (ED25519) навсегда добавлен в список известных хостов.

Это нормально, запустите проверку еще раз, и она должна работать.

person Martin W    schedule 19.02.2020