Я использую SSH для удаленного выполнения команд на сервере (модуль check_by_ssh из Nagios). Но SSH время от времени зависает при попытке выполнить команды. Я могу войти на сервер через SSH, но не выполняю простую команду ls. И, похоже, блокирует всех клиентов с одного IP-адреса. Проблема не в аутентификации, может быть, с помощью ключей SSH или пароля.
ssh -l root -p 2222 server.domain.tld 'ls'
Здесь информация об отладке клиента
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env ORBIT_SOCKETDIR
*** skipping approx 40 env var ignored
debug1: Sending command: ls
debug2: channel 0: request exec confirm 1
Он там висит. Затем через случайное время он снова работает (ничего не делая). Убить весь процесс sshd на сервере, похоже, тоже работает. Работает из шпатлевки. Я видел, что у некоторых людей были такие проблемы из-за проблемы с обратным DNS провайдером, но, похоже, здесь это не так.
Он может работать часами, а затем не работать около получаса.
Чем можно объяснить такое поведение?
РЕДАКТИРОВАТЬ: похоже, что с параметром -t или -T ssh не зависает, но я не могу передать один из этих параметров в check_by_ssh nagios
У меня была такая же проблема, и сегодня я наконец обнаружил, что вызывает проблему (по крайней мере, для меня). Это может вам тоже помочь.
Когда ssh устанавливает сеанс, поле флагов DSCP в IP-заголовке устанавливается на 0x0. Если вы устанавливаете интерактивный сеанс, он устанавливается на 0x10 (16), а если вы устанавливаете неинтерактивный сеанс, он устанавливается на 0x8 (8). Клиент ssh устанавливает поле DSCP с помощью системного вызова setsockopt () (который я проверил в источнике)
Неправильная конфигурация VPN у моего работодателя отбрасывала пакеты с DSCP 0x8, в результате чего весь неинтерактивный ssh-трафик также отбрасывался. Чтобы убедиться, что причиной падения является поле DSCP, я использовал iptables на сервере ssh, чтобы установить для поля DSCP значение 0x16, и протестировал мой неинтерактивный трафик (ssh ls, то же самое, что вы пытались), и он сработал. после этого. Вы также можете попробовать то же самое и посмотреть, почему ваша сессия зависает.
Чтобы установить для DSCP значение 0x10 для всего исходящего ssh-трафика с вашего ssh-сервера, запустите:
$ sudo iptables -t mangle -A ВЫХОД -p tcp --sport 22 -j DSCP --set-dscp 0x19
Это было на коробке rhel 6.5.
Мне пришла идея решить мою проблему из этого блога. У меня тоже очень интересная проблема
У меня есть канал L2vpn (поставщик предоставил MPLS L2) для подключения моего HO и филиала. все тесты подключения ping работали нормально. Когда я использую ssh-сервер debian из HO на сервер debian на стороне клиента, я могу войти на этот сервер, но после удаленного входа ssh на сервер филиала мне не удалось запустить команды ifconfig, htop или ps -ef. Когда я применяю эти команды, сеанс зависает. Evn, что я проверяю его с ПК с Windows, используя шпатлевку, результат был таким же. Интересно то, что когда я использую диспетчер шпатлевки и ssh через это приложение с ПК с Win 7, он работал нормально. После прочтения этого блога я получил информацию о mtu mpls от поставщика услуг и попробовал тот же сценарий с другим размером mtu на интерфейсе исходного сервера debian в HO. Наконец, размер MTU от 1440 до 1470 работал нормально, тогда как по умолчанию размер MTU 1500 не работал. Вывод: размер mtu обоих конечных серверов debian был по умолчанию, то есть 1500, но на полпути, когда у поставщиков услуг размер mtu L2vpn MPLS не совпадал. Спасибо
Возможно, вы используете ограничитель скорости SSH в серверной сети. Это метод брандмауэра для блокировки IP-адресов, которые имеют слишком много новых запросов на соединение в течение короткого периода времени. Затем исходный IP блокируется на определенный период времени.
Проверьте ssh на стороне сервера. Вы можете "привязать" созданный процесс / почтовый процесс sshd и посмотреть, какие системные вызовы он вызывает. Это должно дать вам больше информации о том, что он делает.
Также попробуйте "touch / tmp / randomfile" и посмотрите, зависает ли он после его создания или после него.
Вы проверили, нет ли ошибок PAM? просто потому, что он работает из замазки, это не означает, что проблема не в аутентификации.
Я испытал то же самое при проблемах с MTU. Использование ciscos ipsec client-to-site, а затем openvpn поверх этого. Обычно любой пакет размером 1500 байт замораживает сеанс.
У меня была аналогичная проблема. MTU как клиента, так и сервера составляло 9000. После того, как я снизил MTU клиента до 1500, проблема исчезла.
Возможно ICMP Проблема обнаружения MTU пути.
В нашем деле все Параметры ICMP были заблокированы межсетевым экраном на стороне сервера. Уменьшение MTU на стороне клиента (по рекомендации этот текст) решил проблему временно. Но после разрешения всех (кроме перенаправления) параметров ICMP на стороне сервера проблема исчезла.
Зависание при "отправке команды" может быть вызвано тем, что SSH фактически ожидает ключевую фразу / пароль для ключа. Можно узнать, так ли это, просто сняв команду и подключившись к серверу по SSH без команды в конце. Затем он запросит кодовую фразу.
На моей Linux-машине для сетевого адаптера VMWare vmnet2 MTU было установлено значение 1500. Сеть используется для виртуальной машины, выступающей в качестве интернет-шлюза. После изменения источника с Wi-Fi Интернет на Интернет PPPoE (оптоволокно) удаленный ssh больше не работал. После понижения mtu vmnet2 до 1400 удаленные команды ssh для других серверов ssh снова заработали.
ifconfig vmnet2 mtu 1400 up
Может ли что-то в среде пользовательской оболочки быть заблокированным или задерживаться при открытии? Обходной путь -t / -T и закрытие других сеансов ssh, очищающих его, звучит так, как будто что-то получает блокировку с предположением, что это единственный процесс.