1

Я использую виртуальную машину Google Cloud и время от времени переключаюсь на свой терминал и вижу, что моя сессия ssh зависла. Когда я тогда пытаюсь восстановить соединение

ssh -v  -i ~/.ssh/key  user@host.domain

Это показывает это:

OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/UserName/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 53: Applying options for *
debug1: Connecting to host.domain [123.456.123.456] port 22.
debug1: Connection established.
debug1: identity file /Users/UserName/.ssh/ke> type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/UserName/.ssh/key-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4

Похоже, соединение установлено, но больше ничего не происходит, и мне нужно перезапустить виртуальную машину. Что это значит?

Должен отметить, что я могу без проблем ping с хостом, чтобы он не завис или что-то еще.

1 ответ1

2
debug1: Local version string SSH-2.0-OpenSSH_7.4

Когда клиент подключается к серверу SSH, сервер запускает протокол SSH, отправляя клиенту строку версии сервера в виде простого текста. С помощью утилиты OpenSSH ssh соответствующие строки отладки выглядят так:

debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6

После строки "локальная версия" ваш клиент ожидает, пока сервер отправит свою строку версии клиенту. Если соединение зависает, это потому, что клиент не получил строку версии с сервера.

В общем, есть несколько причин, которые могут вызвать это:

  1. Клиент подключился к чему-то, что не является сервером SSH. Например, HTTP-сервер не будет отправлять что-либо клиенту, поскольку протокол HTTP ожидает, что клиент отправит первые данные.
  2. Сервер работает неправильно. Например, сервер может быть перегружен, и процесс сервера SSH не получает возможности для запуска.
  3. Сервер завис как-то. Например, он может застрять при выполнении DNS-запроса на IP-адресе клиента.
  4. Некоторое сетевое устройство мешает соединению TCP.

В вашем случае вы подключаетесь к порту 22, поэтому можно предположить, что вы подключаетесь к процессу SSH-сервера. Вероятно, вы страдаете от # 2 (сервер работает со сбоями), но невозможно сказать точно, что не так, кроме этого. Вам нужно будет зайти на сервер и выяснить, что происходило в то время, которое мешало ему обрабатывать SSH-соединения.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .