LINUX.ORG.RU
ФорумAdmin

зависает ssh клиент при выполнении команд

 ,


0

1

Внезапно на одном из серверов обнаружилась таинственная проблема, связанная с зависанием SSH клиента, когда необходимо выполнить команду (любую) на сервере. Если добавить клиенту многословности, то выглядит так:

Authenticated to ***.
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x08
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env XDG_SESSION_COOKIE
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = ru_RU.KOI8-R
debug2: channel 0: request env confirm 0
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env _
debug1: Sending command: id
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
И на том останавливается. Спустя долгое время выдаёт «Write failed: Broken pipe» если не прерывать.

Абсолютно идентичное действие при подключении к тому же серверу с другого хоста срабатывает. При том дистр и версии OpenSSH везде одинаковые.

Debian wheezy amd64
OpenSSH версии 6.0p1-2

Путём гугления вышел на нечто бородатое: SSH hangs when executing command remotely

Seems that with -t or -T option, ssh does not hang

При использования ключа -t сессия действительно всегда завершается успешно, однако такой вариант «лечения» как-то не очень годится, как минимум все логи засрутся входами с tty.

Ответ на: комментарий от zolden

Если задать «LogLevel DEBUG2» у sshd:

debug1: Entering interactive session for SSH2.
debug2: fd 4 setting O_NONBLOCK
debug2: fd 7 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug2: session_new: allocate (allocated 0 max 10)
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
Дальше тишина.

По lsof и netstat видно, что подключение активно.

frozen_twilight ★★ ()
Ответ на: комментарий от frozen_twilight

Не, имею в виду логи dmesg или /var/log/messages
Снимите tcpdump, либо погоняйте пинги разного размера для проверки теории про MTU

zolden ★★★★★ ()
Ответ на: комментарий от Slavaz

Никак нет. Видимо, это вылезло после того как в Debian пакет OpenSSH апдейтнулся.

frozen_twilight ★★ ()
Ответ на: комментарий от zolden

имею в виду логи dmesg или /var/log/messages

Ну, ядро тут вряд ли виновато, чтобы в dmesg что-то попадало. Да и sshd всё пишет по умолчанию в /var/log/auth.log.

frozen_twilight ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.