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

Secure Shell (SSH) — это основа удаленного администрирования систем, обеспечивающая зашифрованную связь для доступа к серверам. Однако ошибки подключения могут немедленно остановить работу. Двумя наиболее распространенными и неприятными ошибками, с которыми сталкиваются пользователи, являются "Connection Refused" (Соединение отклонено) и "Permission Denied" (Отказано в доступе).

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

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

Крайне важно различать два основных сообщения об ошибках, поскольку они указывают на совершенно разные первопричины:

Connection Refused (Соединение отклонено): Обычно это означает, что сетевое соединение достигло сервера, но ничто не прослушивало указанный порт, или операционная система активно отклонила попытку соединения.
Permission Denied (Отказано в доступе): Это подразумевает, что служба SSH (sshd) успешно получила запрос на соединение, но попытка аутентификации (пароль или ключ) не удалась на основе конфигурации сервера.

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

"Connection Refused" (часто встречается как ssh: connect to host <hostname> port 22: Connection refused) обычно указывает на проблему на стороне сервера, мешающую демону принимать входящие соединения.

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

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

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

Проверьте статус службы с помощью systemctl (распространено в современных дистрибутивах Linux):

systemctl status sshd

Если статус показывает inactive (неактивно) или failed (ошибка), запустите службу:

sudo systemctl start sshd
# Включите автоматический запуск при загрузке
sudo systemctl enable sshd

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

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

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

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

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

Если вы измените этот файл, вы обязательно должны перезапустить службу sshd, чтобы изменения вступили в силу.

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

Используйте ss или netstat, чтобы убедиться, что sshd активно прослушивает указанный интерфейс и порт. Здесь мы проверяем порт 22:

# Использование ss (предпочтительно в современных системах)
sudo ss -tuln | grep 22

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

Если для порта 22 ничего не отображается, демон либо не запущен, либо настроен для прослушивания другого адреса/порта.

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

Брандмауэр, блокирующий трафик до того, как он достигнет процесса sshd, часто приводит к тайм-ауту, но иногда может проявляться как отказ. Крайне важно подтвердить правила брандмауэра на стороне сервера.

Общие команды для брандмауэра (UFW в Ubuntu/Debian):

Разрешите трафик SSH:

# Проверить текущий статус
sudo ufw status

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

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

⚠️ Предупреждение о внешних брандмауэрах: Если вы подключаетесь из удаленной сети, убедитесь, что любые промежуточные сетевые устройства, группы безопасности облака (например, AWS Security Groups или Azure NSG) или аппаратные брандмауэры явно разрешают трафик на порту SSH.

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

Если вы успешно подключились к серверу, но сразу получили сообщение "Permission denied (publickey,password)" (Отказано в доступе (publickey,password)), проблема заключается исключительно в аутентификации.

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

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

Имя пользователя: Используете ли вы правильное имя пользователя для целевой системы? Вход под root может быть отключен.
Пароль: Если вы используете аутентификацию по паролю, проверьте Caps Lock, опечатки и убедитесь, что учетная запись не заблокирована.

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

ssh -vvv user@hostname

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

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

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

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

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

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

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

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

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

Убедитесь, что ваш открытый ключ (id_rsa.pub или аналогичный) правильно добавлен в файл ~/.ssh/authorized_keys сервера для целевого пользователя. Каждый ключ должен быть на отдельной строке, без переносов строк посередине строки ключа.

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

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

PubkeyAuthentication yes

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

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

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

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

Используйте пары ключей: Отключите аутентификацию по паролю (PasswordAuthentication no) в sshd_config после проверки доступа по ключу.
Измените порт по умолчанию: Перенос SSH с порта 22 уменьшает количество автоматических сканирований.
Используйте PermitRootLogin no: Принудительный административный доступ через стандартных пользователей, заставляя использовать sudo.
Резервное копирование конфигурации: Перед внесением значительных изменений в /etc/ssh/sshd_config всегда создавайте резервную копию исходного файла:
bash sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
Тестируйте локально: После внесения изменений в конфигурацию протестируйте подключение локально на сервере (если возможно) перед отключением активной сессии, чтобы избежать блокировки.

Систематически проверяя статус службы, сетевой путь и уровни конфигурации аутентификации, вы можете быстро устранить неприятные ошибки Connection Refused и Permission Denied, присущие управлению удаленным доступом.