Назад | Перейти на главную страницу

Таймауты подключения SSH2 при выдаче удаленных команд

Я запускаю сценарий, который выдает удаленные команды через SSH на несколько производственных компьютеров. Имеются ключи RSA для подключения пользователя к этим ящикам, и в большинстве случаев проблем не возникает. Время от времени я получаю таймауты соединения, может быть, один раз на каждые 20 соединений.

Я использую SSH2 в качестве протокола, главным образом потому, что SSH2 доступен на всех машинах, к которым я подключаюсь. Вот как выглядит вывод отладки до момента, когда соединение зависает, а затем закрывается.

[mike@dev ~]$ ssh -v -o "Protocol=2" 10.60.###.### "w"
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.60.###.### [10.60.###.###] port 22.
debug1: Connection established.
debug1: identity file /home/mike/.ssh/id_rsa type 1
debug1: identity file /home/mike/.ssh/id_dsa type -1
debug1: loaded 2 keys
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by 10.60.###.###

Подключение здесь зависает, а затем закрывается.

В некоторых случаях соединение проходит немного дальше, но снова зависает.

...
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
Connection closed by 10.60.###.###

Журнал сервера заканчивается примерно так, в случаях, когда соединение умирает:

Jul 23 16:53:07 host02 sshd[4989]: debug1: Client protocol version 2.0; client software version OpenSSH_4.3
Jul 23 16:53:07 host02 sshd[4989]: debug1: match: OpenSSH_4.3 pat OpenSSH*
Jul 23 16:53:07 host02 sshd[4989]: debug1: Enabling compatibility mode for protocol 2.0
Jul 23 16:53:07 host02 sshd[4989]: debug1: Local version string SSH-1.99-OpenSSH_3.9p1
Jul 23 16:53:07 host02 sshd[4990]: debug1: permanently_set_uid: 74/74
Jul 23 16:53:07 host02 sshd[4990]: debug1: list_hostkey_types: ssh-rsa,ssh-dss
Jul 23 16:53:07 host02 sshd[4990]: debug1: SSH2_MSG_KEXINIT sent
Jul 23 16:53:07 host02 sshd[4990]: debug1: SSH2_MSG_KEXINIT received
Jul 23 16:53:07 host02 sshd[4990]: debug1: kex: client->server aes128-cbc hmac-md5 none
Jul 23 16:53:07 host02 sshd[4990]: debug1: kex: server->client aes128-cbc hmac-md5 none
Jul 23 16:53:40 host02 sshd[4990]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
Jul 23 16:53:40 host02 sshd[4990]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
Jul 23 16:53:40 host02 sshd[4990]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
Jul 23 16:53:40 host02 sshd[4990]: Connection closed by ::ffff:192.168.1.203 

На одном сервере, который я тестировал, я обнаружил, что если я вместо этого использую SSH1, я не обнаружил сбоев в подключении. Но мне интересно, можно ли это исправить для SSH2, вместо того, чтобы открывать SSH1 на всех производственных машинах.

Из 100 попыток подключения ...

Используя SSH1: 100 подключений успешно. Используя SSH2: ок. Ошибка 5 подключений.

Я что-то (легкое) упустил?

Мы наконец-то решили это несколько недель назад, и стоит продолжить. Мы запускаем VPN от маршрутизатора нашего локального офиса до брандмауэра в центре обработки данных, оба принадлежат Cisco. Мы обновили IOS на маршрутизаторе и брандмауэре, и, похоже, это помогло.

Спасибо за все идеи / ответы, которые были отправлены.

Может быть проблема с поиском DNS? Зарегистрирован ли IP вашего клиента в DNS? Возможно, тайм-аут происходит при первом поиске, а затем он на некоторое время кэшируется.

Взгляните на TCP-пакеты неудачного соединения. 33 секунды между двумя записями журнала могут быть результатом отбрасывания пакетов базовым соединением или временного сбоя. Шлюз VPN может фактически «офигеть», когда пытается восстановить туннель. В этой ситуации пакеты будут потеряны без уведомления конечной точки TCP.

Просто беги tcpdump -i eth99 -s 0 -w ssh2-problem.pcap port 22 и не удалось установить соединение. Затем используйте Wireshark для проверки файла дампа. Фильтр отображения tcp.flags.syn == 1 and tcp.flags.ack == 0 дает вам только первый пакет потока TCP. Затем используйте «Follow TCP stream» из контекстного меню, закройте диалоговое окно и просмотрите пакеты с ошибочными TCP-потоками. Любые чрезмерные (>> 1) повторные передачи?