SSH не подключается - тайм-аут операции

Question

С этого утра я получаю следующее сообщение об ошибке при попытке подключиться к моему удаленному компьютеру Ubuntu 14.04 LTS через ssh с MacBook Air Yosemite 10.10.1.

ssh_exchange_identification: read: Operation timed out

При использовании флага -vvv появляется следующее подробное сообщение

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: identity file /Users/felix/.ssh/id_rsa type -1
debug1: identity file /Users/felix/.ssh/id_rsa-cert type -1
debug1: identity file /Users/felix/.ssh/id_dsa type -1
debug1: identity file /Users/felix/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Operation timed out

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

Любые предложения о том, как решить эту проблему?

Answer 1

debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Operation timed out

Согласно вашей трассировке отладки, вам удается подключиться к удаленному SSH-серверу, и сервер не прерывает соединение, но сервер не отправляет свою строку идентификации программного обеспечения. Это первое, что делается клиентом и сервером, и это делается открытым текстом.

Я думаю, что проблема сводится к одной из трех вещей:

1. Некоторое сетевое устройство между вами и сервером мешает соединению. Например, если удаленный хост находится за маршрутизатором NAT, переадресация порта для порта 22 может быть настроена неправильно, и вы подключаетесь к неправильной службе.

2. Программа сервера SSH на удаленном хосте может зависать или работать неправильно. Я видел подобные вещи, например, когда хост сильно перегружен или не хватает виртуальной памяти. Или сервер может использовать что-то вроде обертки TCP, и он делает запрос DNS на IP-адрес вашего клиента, который занимает много времени для разрешения.

3. Удаленный хост настроен необычным образом, а служба, работающая на порту 22, не является сервером SSH.

Если вы можете добраться до сервера, сфокусируйте свои проблемы там. Найдите журналы для сервера ssh - они должны быть в /var/log и посмотреть, не записал ли он что-нибудь об этих неудачных попытках подключения. Попробуйте запустить ssh для localhost с сервера и посмотреть, работает ли он правильно.

Если у вас есть root-доступ к серверу, вы можете попробовать запустить отладочный экземпляр sshd чтобы посмотреть, что он записывает в журнал при подключении вашего клиента. Завершите работу обычного sshd сервера и в окне корневого терминала запустите /path/to/sshd -d . Это запустит копию sshd, которая примет одно соединение и выведет отладочную информацию в окно терминала. Посмотрите, сможете ли вы воспроизвести проблему, а затем проверьте, что сервер зарегистрировал.

Если вы не можете перевести обычный ssh-сервер в автономный режим, вы можете запустить sshd на другом порту: /path/to/sshd -p 42 -d запускает копию sshd, прослушивающую порт 42. При запуске клиента ssh укажите тот же номер порта: ssh -p 42 user@host . Если ваши проблемы связаны с мешающим сетевым устройством, это может вести себя иначе, чем подключение к порту 22.