Устранение распространенных ошибок SSH: Connection Refused и Permission Denied

Ошибки SSH легче исправить, если разделять проблемы транспорта и аутентификации. Connection refused означает, что ваш SSH-клиент достиг хоста, но ничто не приняло TCP-соединение на этом порту. Permission denied означает, что SSH-сервер ответил, но отклонил ваш вход в систему. Это разные инциденты, даже если оба ощущаются как "я не могу войти".

Держите одно активное SSH-соединение открытым при изменении настроек сервера. Самые болезненные сбои SSH происходят, когда кто-то редактирует /etc/ssh/sshd_config, перезапускает службу, отключается и только тогда обнаруживает, что новая конфигурация блокирует все пути входа.

Понимание ошибок: Refused vs. Denied

Прочитайте точное сообщение клиента перед любыми изменениями:

Connection refused: хост активно отклонил TCP-соединение, обычно потому что sshd не прослушивает этот порт или брандмауэр его отклоняет.
Connection timed out: пакеты теряются или сетевой путь нарушен. Это более вероятно из-за брандмауэра, маршрута, VPN, группы безопасности или неверного IP.
Permission denied (publickey): сервер доступен, но не принял ваш ключ.
Permission denied (publickey,password): сервер попробовал один или несколько методов аутентификации и отклонил их.
Host key verification failed: ваш клиент не доверяет идентичности сервера, представленной для этого имени хоста или IP.

Часть 1: Устранение ошибки Connection Refused

ssh: connect to host example port 22: Connection refused обычно указывает на удаленный хост или порт. Машина ответила, но SSH не принимал соединения там.

1. Проверка статуса демона SSH (sshd)

Наиболее частая причина отказа — процесс SSH-сервера не запущен или упал.

Действия (на удаленном сервере):

На многих дистрибутивах Linux служба называется sshd; на Debian и Ubuntu она часто называется ssh. Попробуйте ту, которую использует ваша система:

systemctl status sshd
systemctl status ssh

Если служба неактивна или завершилась с ошибкой, запустите ее:

sudo systemctl start sshd
sudo systemctl enable sshd

Если sshd не запускается после изменения конфигурации, проверьте конфигурацию:

sudo sshd -t

Эта команда — одна из самых безопасных проверок, которые можно выполнить перед перезапуском SSH.

2. Проверка прослушиваемого порта и конфигурации

По умолчанию SSH использует TCP-порт 22, но многие серверы используют другой порт. Если сервер прослушивает порт 2222, команда клиента должна включать его:

ssh -p 2222 [email protected]

A. Просмотр `sshd_config`

Изучите файл конфигурации SSH, обычно расположенный по адресу /etc/ssh/sshd_config. Найдите директиву Port:

# /etc/ssh/sshd_config example
Port 2222  # Если это не 22, вам нужно указать его на стороне клиента

После редактирования файла выполните sudo sshd -t перед перезагрузкой. Если синтаксис верен, перезагрузите или перезапустите службу. Перезагрузка обычно менее разрушительна:

sudo systemctl reload sshd

B. Проверка прослушиваемых сокетов

Используйте ss, чтобы подтвердить, что sshd прослушивает:

sudo ss -tuln | grep 22

# Ожидаемый вывод, показывающий статус прослушивания:
# LISTEN 0      128    0.0.0.0:22               0.0.0.0:*

Если SSH прослушивает только 127.0.0.1:22, удаленные клиенты не смогут подключиться. Если он прослушивает 0.0.0.0:22 или конкретный частный интерфейс, удаленный доступ может быть возможен в зависимости от правил брандмауэра.

3. Проверка брандмауэра и сети

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

Типичные команды брандмауэра (UFW на Ubuntu/Debian):

Убедитесь, что трафик SSH разрешен:

# Проверка текущего статуса
sudo ufw status

# Разрешить трафик на порт по умолчанию 22
sudo ufw allow ssh
# ИЛИ по номеру порта
sudo ufw allow 22/tcp

# Перезагрузить правила брандмауэра
sudo ufw reload

Облачные группы безопасности, сетевые ACL, VPN-маршруты и офисные брандмауэры могут блокировать SSH до того, как трафик достигнет сервера. Если sshd прослушивает и брандмауэр хоста открыт, протестируйте с машины внутри той же частной сети. Это покажет, проблема локальна для сервера или находится где-то на внешнем пути.

Часть 2: Устранение ошибки Permission Denied

Если сервер отвечает Permission denied, сетевой путь работает. Сосредоточьтесь на имени пользователя, разрешенных методах аутентификации, ключах, состоянии учетной записи и разрешениях файлов.

1. Проверка имени пользователя и пароля

Это самая простая проверка, но ее часто упускают из виду:

Имя пользователя: Облачные образы часто используют определенных пользователей, таких как ubuntu, ec2-user, admin, debian или rocky. root может быть отключен.
Пароль: Если аутентификация по паролю включена, проверьте опечатки, блокировку учетной записи, истекшие пароли и правила PAM.
Порт и хост: Удивительное количество ошибок аутентификации вызвано подключением к неверному серверу, на котором случайно работает SSH.

Проверка на стороне клиента: Чтобы увидеть подробный отладочный вывод, запустите клиент с подробными флагами:

ssh -vvv user@hostname

Этот вывод четко покажет, какие методы аутентификации клиент пытался использовать и какие сервер отклонил.

2. Ошибки аутентификации по ключу

Аутентификация по ключу не удается, когда клиент предлагает неверный закрытый ключ, на сервере нет соответствующего открытого ключа, разрешения слишком открыты или sshd_config блокирует вход.

A. Неверные разрешения на каталог `.ssh`

SSH чрезвычайно строг к разрешениям файлов из соображений безопасности. Если разрешения слишком открыты, сервер полностью проигнорирует файл ключа.

На удаленном сервере (исправление разрешений):

# Разрешения домашнего каталога пользователя обычно в порядке, но проверьте папку .ssh
chmod 700 ~/.ssh

# Файл authorized_keys должен быть доступен для записи только владельцу
chmod 600 ~/.ssh/authorized_keys

Также проверьте владельца:

chown -R "$USER:$USER" ~/.ssh

На сервере StrictModes обычно включен. Если домашний каталог, каталог .ssh или файл authorized_keys доступен для записи другим пользователям, sshd может игнорировать ключ.

B. Ключ отсутствует или имеет неверный формат

Убедитесь, что открытый ключ находится в ~/.ssh/authorized_keys целевого пользователя, по одному ключу на строку. Закрытый ключ остается на вашем клиенте. Не вставляйте закрытый ключ в authorized_keys.

Со стороны клиента укажите конкретный ключ при отладке:

ssh -i ~/.ssh/id_ed25519 -vvv [email protected]

В подробном выводе ищите строки, показывающие, какие ключи были предложены и почему сервер принял или отклонил их.

C. Конфигурация сервера, отключающая ключи

Проверьте /etc/ssh/sshd_config на сервере, чтобы убедиться, что аутентификация по ключу разрешена:

PubkeyAuthentication yes

# Убедитесь, что аутентификация по паролю не отключена, если вы полагаетесь на пароли
PasswordAuthentication yes

Если присутствуют AllowUsers, AllowGroups, DenyUsers или DenyGroups, они могут переопределить то, что выглядит как правильная настройка ключа. Пользователь с правильным ключом все равно может быть заблокирован этими директивами.

3. Исследование журналов на стороне сервера

Журналы сервера обычно сообщают реальную причину отказа. Держите терминал открытым на сервере и наблюдайте за журналами при попытке входа с клиента.

Типичные расположения журналов:

Debian/Ubuntu: /var/log/auth.log
RHEL/CentOS/Fedora: /var/log/secure

Используйте grep для фильтрации последних попыток подключения:

# На системах RHEL/CentOS
sudo grep 'Failed password' /var/log/secure

# Или ищите общую активность SSH
sudo tail -f /var/log/secure

В системах с systemd journaling это часто проще:

sudo journalctl -u sshd -f
sudo journalctl -u ssh -f

Сообщения журнала могут показывать "bad ownership or modes", "user not allowed", "invalid user", "authentication refused" или ошибки учетной записи PAM. Эти сообщения более надежны, чем догадки только со стороны клиента.

Ошибки проверки ключа хоста

Host key verification failed — это не то же самое, что неверный пароль или ключ. Это означает, что ваш клиент сохранил идентичность сервера для этого имени хоста или IP, а сервер теперь представляет другую идентичность. Это может произойти после пересборки, повторного использования IP, изменения балансировщика нагрузки или реального риска "человек посередине".

Не удаляйте предупреждение вслепую в производственной среде. Проверьте отпечаток сервера через облачную консоль, систему управления конфигурацией или существующий доверенный канал. Как только вы узнаете, что изменение ожидаемо, удалите старую запись:

ssh-keygen -R example.com
ssh-keygen -R 192.0.2.10

Затем подключитесь снова и примите новый ключ хоста только в том случае, если отпечаток совпадает с ожидаемым.

Краткое изложение лучших практик для надежного доступа по SSH

Используйте пары ключей: Отключайте аутентификацию по паролю только после того, как проверили доступ по ключу во второй сессии.
Ограничьте, кто может входить: Используйте AllowUsers или AllowGroups при необходимости, но документируйте это, чтобы будущие операторы не гонялись за ложными проблемами с разрешениями.
Используйте PermitRootLogin no: Предпочитайте обычных пользователей с sudo.
Резервируйте конфигурацию: Перед изменением /etc/ssh/sshd_config скопируйте его:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) ``` 5. Проверяйте перед перезагрузкой: Выполните sudo sshd -t. 6. Держите аварийный путь: Для облачных серверов знайте, как использовать последовательную консоль, режим восстановления, функцию подключения к экземпляру или управление конфигурацией, если SSH сломается.

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