Что сделать, если зависает ssh

Общий алгоритм диагностики и восстановления SSH-подключения

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

1. Немедленные действия на стороне клиента

Сначала попробуйте "разорвать" зависшее соединение безопасно:

• Используйте escape-последовательность: Нажмите Enter, затем введите ~. (тильда и точка). Это стандартная последовательность для принудительного разрыва соединения.

  # В зависшей сессии наберите:
  ~.
  

• Используйте комбинации клавиш: Попробуйте Ctrl+C, Ctrl+D, Ctrl+\.
• Закройте окно терминала: Если предыдущие методы не сработали, закройте окно терминала или сессию.
• Найдите и завершите процесс SSH: Если сессия не закрылась, найдите и убейте процесс.

  # Найти PID процесса ssh
  ps aux | grep ssh
  
  # Завершить процесс
  kill -9 <PID_ssh_process>
  

2. Базовая диагностика сети и сервера

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

• Проверьте доступность сервера:

  ping <ip_адрес_сервера>
  

    Если ping не проходит, проблема на сетевом уровне (фаервол, роутинг, проблемы у провайдера).

• Проверьте, слушает ли сервер порт SSH (обычно 22):

  nc -zv <ip_адрес_сервера> 22
  # или
  telnet <ip_адрес_сервера> 22
  

• Попробуйте подключиться с увеличенным уровнем логирования: Это поможет понять, на каком этапе происходит зависание.

  ssh -vvv user@server_ip
  

    Ключевые моменты в логе: `Authentication succeeded` (успешная аутентификация) или `Entering interactive session`. Если зависание происходит после этого, проблема, скорее всего, в оболочке (shell) или настройках сессии.

3. Распространённые причины и их решение

A. Проблемы на стороне сервера (требуется альтернативный доступ)

Если есть возможность подключиться через консоль (KVM, IPMI, VNC) или другой SSH-демон на другом порту, проверьте:

1. Загрузка системы (Load Average) и память: Используйте top, htop, free -m. Высокая загрузка или нехватка памяти (OOM - Out Of Memory) могут блокировать новые процессы.
2. Заполнение файловых систем: Особенно / и /var. Используйте df -h. Заполнение диска на 100% часто ломает многие операции.

   df -h | grep -E '^(Filesystem|/)'
   

3. Проблемы с демоном SSH: Перезапустите службу SSH.

   # Systemd
   sudo systemctl restart sshd
   # Проверить статус и логи
   sudo systemctl status sshd
   sudo journalctl -u sshd -n 50
   

4. Конфигурация SSH: Проверьте корректность /etc/ssh/sshd_config. Временное упрощение конфигурации (например, отключение UsePAM или UseDNS) может помочь в диагностике.

   sudo sshd -t # Проверка синтаксиса конфига перед рестартом
   

5. Фаервол (iptables/nftables): Правила могут блокировать или "ронять" соединения. Проверьте текущие правила.

   sudo iptables -L -n -v
   sudo nft list ruleset
   

6. Проблемы с DNS (UseDNS): Если в sshd_config стоит UseDNS yes, а сервер не может резолвить обратный DNS клиента, это может вызвать задержки. Поставьте UseDNS no и перезапустите sshd.
7. Сессия пользователя (shell, профиль): Попробуйте подключиться под другим пользователем или с ключом, который запускает простую команду вместо интерактивной сессии.

   ssh user@server_ip "ls -la"
   

    Если это работает, проблема в `.bashrc`, `.bash_profile`, `.profile` или в переменных окружения (`$PATH`, `$LD_*`) вашего пользователя. Проверьте эти файлы на наличие "тяжёлых" операций (сетевые вызовы, запуск приложений).

B. Проблемы на стороне клиента

1. Локальный фаервол/антивирус: Может обрывать длительные idle-соединения.
2. Таблица маршрутизации клиента: Проверьте маршрут до сервера.
3. Клиентские настройки SSH (~/.ssh/config): Проверьте на наличие нестандартных опций (ServerAliveInterval, ProxyCommand). Попробуйте подключиться без конфига:

   ssh -F /dev/null user@server_ip
   

C. Сетевые проблемы "посередине"

1. Ненадёжная сеть с потерей пакетов: Используйте mtr или traceroute для диагностики.
2. Пассивное обрывание соединений (Inactive Timeout) на промежуточных устройствах: Настройте на клиенте опции ServerAliveInterval и ServerAliveCountMax в ~/.ssh/config. Они будут периодически отправлять keep-alive пакеты.

   Host *
       ServerAliveInterval 60
       ServerAliveCountMax 3
   

4. Профилактика и лучшие практики

• Всегда используйте tmux или screen: Это позволит переподключиться к существующей сессии при обрыве связи.

  tmux new -s mysession
  # После разрыва и повторного входа:
  tmux attach -t mysession
  

• Настройте keep-alive как на клиенте (см. выше), так и на сервере (в /etc/ssh/sshd_config: ClientAliveInterval 60, ClientAliveCountMax 3).
• Настройку сервера всегда проводите через консоль управления или в сессии tmux, чтобы не потерять доступ при ошибке в конфиге SSH.
• Имейте альтернативный метод доступа к серверу (консоль в облаке, второй SSH-демон на резервном порту с простой конфигурацией).
• Включите логирование SSH на адекватном уровне и мониторьте логи.

Итог: Диагностику зависания SSH нужно начинать с определения этапа, на котором оно происходит (до аутентификации, после, в интерактивной сессии), используя ssh -vvv. Основные направления: проверка ресурсов сервера (память, диск), корректность службы SSH и её конфигурации, а также сетевые проблемы. Использование tmux и keep-alive сообщений — ключевая практика для стабильной работы.