Решаем проблемы с SSH-подключением в Linux: полное руководство

Введение / Зачем это нужно

SSH (Secure Shell) — это основной инструмент для удалённого управления Linux-серверами. Проблемы с подключением могут парализовать работу: вы не сможете развернуть приложение, обновить систему или даже восстановить доступ после сбоя. Этот гайд систематизирует диагностику, начиная от простой проверки сети и заканчивая анализом логов. Вы получите чёткий алгоритм действий, который сработает на большинстве дистрибутивов (Ubuntu, Debian, CentOS, Arch).

Требования / Подготовка

Доступ к консоли на целевом сервере (через KVM, iLO, консоль в панели хостинга) или доступ с другого рабочего узла в сети.
Права sudo или root на сервере для перезапуска служб и просмотра логов.
Установленный клиент openssh-client на вашей локальной машине.
Базовое понимание командной строки Linux.

Шаг 1: Проверка базовой сетевой доступности

Прежде чем копаться в конфигурации SSH, убедитесь, что сервер вообще доступен по сети, а порт SSH открыт.

# 1. Проверяем, отвечает ли хост (замените server_ip на IP или домен)
ping -c 4 server_ip

# 2. Проверяем, открыт ли порт SSH (по умолчанию 22) с помощью netcat (nc)
# Установите nc, если его нет: sudo apt install netcat (Debian/Ubuntu) или sudo yum install nc (RHEL/CentOS)
nc -zv server_ip 22

# Альтернатива с nmap (если установлен)
nmap -p 22 server_ip

Результат nc: Connection to server_ip 22 port [tcp/ssh] succeeded! — порт открыт.
Результат nc: Connection refused — порт закрыт или служба не слушает.
Результат nc: No route to host или таймаут — проблемы на сетевом уровне (фаервол, маршрутизация, хост выключен).

⚠️ Важно: Если ping не работает, проблема не в SSH, а в сети. Проверьте настройки IP, шлюз, фаервол локальной машины и промежуточных устройств.

Шаг 2: Диагностика службы SSH на сервере

Если порт открыт, но подключение не устанавливается, проверьте, работает ли демон sshd.

# 1. Проверьте статус службы (для systemd)
sudo systemctl status sshd

# 2. Узнайте, на каком порту(ах) служит служба
sudo ss -tlnp | grep sshd
# Или
sudo netstat -tlnp | grep sshd

Типичные сценарии:

Служба неактивна (inactive): Запустите её: sudo systemctl start sshd и включите автозагрузку: sudo systemctl enable sshd.
Служба слушает не на 0.0.0.0:22 (или :::22), а только на 127.0.0.1:22: Это значит, что sshd настроен принимать подключения только локально. Проверьте параметр ListenAddress в конфиге (см. Шаг 3).
Служба слушает на нестандартном порту (например, 2222): Либо измените порт в клиенте (ssh -p 2222 user@host), либо верните стандартный в конфиге.

Шаг 3: Анализ конфигурации SSH-сервера

Основной конфигурационный файл — /etc/ssh/sshd_config. Вносите изменения с осторожностью, делайте бэкап: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.

# Просмотрите текущую конфигурацию, игнорируя комментарии
sudo cat /etc/ssh/sshd_config | grep -v "^#" | grep -v "^$"

Критические параметры для проверки:

Параметр	Рекомендуемое значение / Что проверить
`Port`	Убедитесь, что порт совпадает с тем, на который вы пытаетесь подключиться (по умолчанию `22`).
`ListenAddress`	Должен быть `0.0.0.0` (все интерфейсы) или конкретный IP сервера. Если закомментирован — используется по умолчанию.
`PermitRootLogin`	`prohibit-password` (рекомендуется) или `no`. Если нужно логин под root, временно можно поставить `yes` для диагностики.
`PasswordAuthentication`	`yes` (если хотите использовать пароль) или `no` (если только ключи).
`PubkeyAuthentication`	Должен быть `yes`, если используете аутентификацию по ключу.
`AllowUsers` / `AllowGroups`	Если эти директивы есть, убедитесь, что ваш пользователь указан в списке.
`DenyUsers` / `DenyGroups`	Убедитесь, что ваш пользователь не запрещён.

После любого изменения конфига необходимо перезапустить службу:

sudo systemctl restart sshd

Шаг 4: Проверка прав на файлы и папки SSH (для аутентификации по ключу)

SSH-сервер очень строг к правам на файлы. Неправильные права — частая причина Permission denied (publickey).

На сервере (под пользователем, под которым вы пытаетесь войти):

# 1. Проверьте права на домашнюю директорию пользователя
ls -ld ~

# 2. Проверьте права на папку .ssh
ls -ld ~/.ssh

# 3. Проверьте права на файл authorized_keys
ls -l ~/.ssh/authorized_keys

Правильные права:

Домашняя директория (/home/username): drwxr-xr-x (755) или строже.
Папка .ssh: drwx------ (700).
Файл authorized_keys: -rw------- (600).
Владелец всех этих объектов — сам пользователь, под которым идёт вход.

Исправление прав:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
# Иногда помогает:
chown -R username:username ~/.ssh

💡 Совет: Если вы только что сгенерировали ключ и скопировали его на сервер, убедитесь, что вы копировали публичный ключ (файл id_ed25519.pub или id_rsa.pub), а не приватный, и что он добавлен в authorized_keys как одна строка.

Шаг 5: Анализ логов SSH

Логи — самый надёжный источник истины. Где смотреть, зависит от дистрибутива.

# Для RHEL/CentOS/Fedora/AlmaLinux/Rocky Linux и родственных:
sudo tail -f /var/log/secure

# Для Debian/Ubuntu и родственных:
sudo tail -f /var/log/auth.log

# Универсальный способ через systemd journal (работает везде):
sudo journalctl -u sshd -f

Что ищем в логах:

Failed password for ... — ошибка пароля.
Connection closed by ... — клиент разорвал соединение, часто из-за проблем с ключом.
Authentication refused: bad ownership or modes for directory /home/... — неправильные права (см. Шаг 4).
User ... not allowed because not listed in AllowUsers — пользователь запрещён в конфиге.
Received disconnect from ...: 11: Bye Bye — может указывать на проблему с сессией или ключом.
Invalid user ... — попытка войти под несуществующим пользователем.

Пример для быстрой фильтрации по IP или пользователю:

sudo journalctl -u sshd | grep "192.168.1.100"
sudo journalctl -u sshd | grep "user_login"

Шаг 6: Тестирование подключения с отладкой (клиентская сторона)

Запустите подключение с максимальной детализацией. Это покажет, на каком именно этапе происходит сбой.

# Максимально подробные логи (3 уровня -v)
ssh -vvv user@server_ip

На что обратить внимание в выводе:

debug1: Connecting to server_ip [server_ip] port 22. — клиент нашёл хост и порт.
debug1: Connection established. — TCP-соединение прошло.
debug1: Authenticating to server_ip:22 as 'user' — начало аутентификации.
debug1: Offering public key: /home/you/.ssh/id_ed25519 ... — клиент предлагает ключ. Если ключ не предлагается, возможно, агент ssh-agent не запущен или ключ не добавлен (ssh-add -l).
debug1: Authentications that can continue: publickey,password — сервер сообщил, какие методы аутентификации он принимает.
debug1: Offering public key: ... повторяется, затем debug1: Authentications failed. — сервер отклонил ключ (проблема на стороне сервера: ключ не в authorized_keys, неправильные права, SELinux).
Если после этого идёт debug1: Next authentication method: password, значит, сервер принял переход к паролю (если PasswordAuthentication yes).

Клиентские опции для тестов:

# Отключить использование ключей (проверить парольную аутентификацию)
ssh -o PubkeyAuthentication=no user@server_ip

# Указать конкретный ключ
ssh -i ~/.ssh/my_specific_key user@server_ip

# Отключить проверку known_hosts (опасно, только для теста!)
ssh -o StrictHostKeyChecking=no user@server_ip

Проверка результата

Успешное подключение завершится приглашением командной строки удалённого сервера. В логах клиента (-vvv) вы увидите строки:

debug1: Authentication succeeded (publickey).
Authenticated to server_ip ([server_ip]:22).

На сервере в логах появится запись:

Accepted publickey for user from client_ip port client_port ssh2: ED25519 SHA256:...

Возможные проблемы

Симптом	Вероятная причина	Решение
`ssh: connect to host server_ip port 22: Connection refused`	Служба `sshd` не запущена, слушает на другом порту или блокируется фаерволом.	Запустите `sshd` (`sudo systemctl start sshd`). Проверьте порт (`ss -tlnp`). Проверьте фаервол (`sudo ufw status` или `sudo firewall-cmd --list-all`).
`ssh: connect to host server_ip port 22: Operation timed out`	Сетевой трафик блокируется на маршруте (фаервол на сервере, облачный Security Group, провайдер).	Проверьте все фаерволы: на сервере (`iptables -L -n`, `ufw`, `firewalld`), в панели управления хостинга/облака (Security Groups, Network ACLs).
`Permission denied (publickey,password).`	1. Неверный/отсутствующий ключ в `authorized_keys`. 2. Неправильные права на файлы `.ssh`. 3. Пользователь запрещён в `sshd_config` (`AllowUsers`, `DenyUsers`). 4. SELinux/AppArmor блокирует доступ.	1. Перекопируйте ключ. 2. Исправьте права (700/600). 3. Проверьте `sshd_config` на запреты. 4. Проверьте логи SELinux (`sudo ausearch -m avc -ts recent`). Временно отключите: `sudo setenforce 0` (для диагностики).
`The authenticity of host 'server_ip (server_ip)' can't be established.`	Вы подключаетесь к серверу впервые, его ключ отсутствует в `~/.ssh/known_hosts`.	Это предупреждение, а не ошибка. Если уверены в сервере, введите `yes`. Если ключ изменился (например, переустановка ОС), удалите старую запись: `ssh-keygen -R server_ip`.
`Connection closed by remote host`	Сервер разрывает соединение на этапе аутентификации. Часто из-за несовпадения ключей или проблем с сессией.	Проверьте логи `sshd` на предмет ошибок. Убедитесь, что в `sshd_config` нет ограничений по `MaxSessions`, `ClientAliveInterval`.

Дополнительные методы диагностики

Если стандартные шаги не помогли, проверьте следующее:

Проверка фаервола на сервере (UFW example):

sudo ufw status numbered
# Если правило для 22/tcp отсутствует, добавьте:
sudo ufw allow 22/tcp

Проверка SELinux/AppArmor:

# Для SELinux (RHEL/CentOS/Fedora)
sudo sestatus
sudo ausearch -m avc -ts recent | grep sshd
# Для AppArmor (Debian/Ubuntu)
sudo aa-status | grep sshd

Проверка файла /etc/hosts.allow и /etc/hosts.deny: Эти файлы могут блокировать доступ. Убедитесь, что в hosts.allow есть строка sshd: ALL или ваш IP, а в hosts.deny нет sshd: ALL.
Проверка ресурсов сервера: Если сервер перегружен (нет памяти, места на диске), sshd может не принимать новые соединения. Проверьте: free -h, df -h, top.
Тест с другого клиента: Попробуйте подключиться с другой машины. Если работает — проблема в исходном клиенте (его ключи, конфиг ~/.ssh/config, фаервол).
Временное увеличение уровня логирования в sshd_config: Раскомментируйте или добавьте LogLevel DEBUG и перезапустите sshd. Не забывайте вернуть INFO после диагностики!

sudo sed -i 's/^#LogLevel.*/LogLevel DEBUG/' /etc/ssh/sshd_config
sudo systemctl restart sshd
# ... выполняем попытку подключения ...
# Возвращаем обратно:
sudo sed -i 's/^LogLevel.*/LogLevel INFO/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Заключение

Диагностика SSH-проблем — это последовательный процесс исключения: сеть -> служба -> конфиг -> права -> логи. Начните с простых проверок (ping, nc, systemctl status sshd), а затем углубляйтесь в конфигурацию и права. Логи (journalctl -u sshd или /var/log/auth.log) почти всегда содержат конкретную причину отказа. Используйте клиентский режим отладки (ssh -vvv), чтобы увидеть процесс с другой стороны. После устранения проблемы не забудьте вернуть настройки безопасности (например, LogLevel и PermitRootLogin) в исходное состояние.

Часто задаваемые вопросы

Что делать, если SSH требует пароль, хотя ключ настроен?

Проверяю порт 22 командой `nmap`, но он закрыт. Почему?

Можно ли временно отключить проверку ключей для диагностики?

Почему после смены порта в sshd_config подключение не работает?

Полезное

Проверка базовой сетевой доступности

Диагностика службы SSH на сервере

Анализ конфигурации SSH-сервера

Проверка прав на файлы и папки SSH

Анализ логов SSH

Тестирование подключения с отладкой