Ошибки SSH на VPS Ubuntu: как найти причину

Зафиксируйте одну попытку и сохраните доступ

Команды клиента выполняются на вашем компьютере в Linux, macOS или WSL. Серверные команды — через работающую SSH-сессию или доверенную консоль. Не вставляйте команды сервера в локальный терминал.

Замените 203.0.113.10, ubuntu, порт 22 и путь ключа своими значениями. Адрес в примере предназначен для документации. Сначала выведите применённые настройки клиента, затем сделайте свежую попытку соединения.

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Посмотрите hostname, user, port, identityfile и настройки proxy. Во второй команде отключено совместное использование соединения. Запишите время и итоговую ошибку. Новый ключ хоста проверяйте по разделу ниже; перед передачей отладочного вывода уберите адреса, имена и пути, не передавайте закрытый ключ.

Определите этап сбоя

Прокрутите таблицу, чтобы увидеть остальные столбцы →

Это направления проверки, а не доказательство одной причины. Если до тайм-аута есть Connection established, исследуйте SSH-обмен и журналы сервера, а не предполагайте, что все пакеты изначально блокировались.

При тайм-ауте проверьте сетевой путь

Сравните адрес в ssh -v с текущим адресом в панели. Устаревший DNS или другой IPv6 может направить запрос не туда. Уточните, требуется ли публичный адрес, VPN или промежуточный SSH-хост.

Проверьте состояние VM, публичный маршрут, реальный порт SSH и текущий публичный адрес источника. Домашний адрес может измениться, пока правило /32 осталось прежним. Гостевой firewall проверьте через консоль.

В Oracle важны security lists, NSG, маршрут и правила образа. Не устанавливайте UFW и не очищайте iptables ради диагностики. Схема описана в инструкции создания Oracle VM. Неудачный ping сам по себе не доказывает недоступность SSH.

При отказе соединения проверьте слушающую службу

Отказ не удостоверяет, что вы попали на нужный VPS. Подтвердите адрес и порт, затем выполните проверки на сервере через сохранённый доступ или аварийную консоль.

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Найдите слушающий адрес и порт, сопоставьте журнал со временем попытки. Ubuntu может использовать socket activation: неактивная ssh.service не доказывает отказ, если ssh.socket слушает порт.

sshd -t проверяет конфигурацию и ключи хоста, не запуская службу. Отсутствие вывода при успехе не означает доступность из Интернета. При ошибке сначала найдите конкретный файл или параметр; не перезапускайте службу вслепую.

При отклонении ключа проверьте пользователя и файл

Используйте начального пользователя провайдера или созданного администратора, а не угаданное имя. В отладочном выводе найдите отпечаток предложенного ключа. Для ограничения посторонних ключей агента повторите попытку локально:

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Настроенные IdentityFile всё ещё могут применяться: проверьте ssh -G. Если клиент не читает ключ или сообщает о слишком широких правах, сначала исправьте локальный файл, а не сервер.

На VPS проверьте целевого пользователя, его реальный домашний каталог и разрешённые публичные ключи. Пример предполагает /home/ubuntu; замените его результатом getent.

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

Сравните разрешённые отпечатки с предложенным. Проверьте журнал на ошибки владельца, прав и политики аккаунта. Учитывайте AuthorizedKeysFile, include, Match и управляемые сервисы ключей провайдера. Сохраните существующие ключи. Не отключайте StrictModes и не включайте пароли, чтобы скрыть причину.

При смене ключа хоста сначала подтвердите подлинность

Пересоздание VM или повторное использование IP может изменить ключ. Неожиданное изменение также может означать неверный сервер или перехват. Подтвердите идентификатор инстанса и плановую пересборку в своём аккаунте провайдера.

Через доверенную консоль гостевой системы прочитайте публичный ключ того же алгоритма, который показал клиент. Для Ed25519:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Сравните SHA256 с предупреждением. Это ключ сервера, не ваш ключ входа и не ключ консольного шлюза провайдера. После подтверждённой замены сделайте копию known_hosts и обновите только запись этого хоста и порта. Не удаляйте весь файл и не отключайте проверку. Необъяснённое различие требует остановить соединение и разобраться.

Проверьте конкретное исправление новым входом

Исправьте установленную причину: адрес, имя пользователя, ключ, узкое сетевое правило или ошибку конфигурации. Сохраняйте независимый доступ и проверяйте синтаксис SSH до применения. Новый порт может затрагивать socket activation, а не только перезапуск службы.

Повторите исходную попытку без совместного использования соединения. Подтвердите нужного пользователя и sudo, если оно требуется. Старая работающая сессия не заменяет новый вход. Запишите причину и изменение.

После восстановления вернитесь к настройке VPS Ubuntu. Перед следующими значительными изменениями подготовьте проверенную копию файлов.

Вопросы и ответы