SSH не подключается: диагностика по слоям

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

Алгоритм диагностики

Шаг 1. DNS и базовая доступность

# Проверить DNS-разрешение
ping -c 3 server.example.com

# Если ping не проходит — проверить IP напрямую
ping -c 3 192.168.1.10

# DNS-резолюция отдельно
dig server.example.com +short
nslookup server.example.com

Если ping IP работает, а ping hostname нет — проблема в DNS, не в сервере.

Шаг 2. Порт SSH открыт?

# Проверить что порт отвечает (по умолчанию 22)
nc -zv server.example.com 22

# Если нестандартный порт (например 2906)
nc -zv server.example.com 2906

# Альтернатива через telnet
telnet server.example.com 22

# Через nmap (если установлен)
nmap -p 22 server.example.com

Ожидаемый ответ nc: Connection to server.example.com 22 port [tcp/ssh] succeeded!

Если соединение не установлено — причина в сети или firewall на сервере, до SSH дело не доходит.

Шаг 3. Firewall на сервере

# UFW (Ubuntu)
sudo ufw status verbose
# SSH должен быть в ALLOW

# iptables
sudo iptables -L INPUT -n --line-numbers | grep -E '22|ssh'

# firewalld (CentOS/RHEL)
sudo firewall-cmd --list-all

# Быстро разрешить SSH в UFW если заблокирован:
sudo ufw allow 22/tcp
# или для нестандартного порта:
sudo ufw allow 2906/tcp

Шаг 4. sshd запущен и работает

# Статус демона
sudo systemctl status sshd

# Если не запущен:
sudo systemctl start sshd
sudo systemctl enable sshd

# Проверить на каком порту слушает
sudo ss -tlnp | grep sshd
# Ожидаемо: 0.0.0.0:22 или 0.0.0.0:2906

# Логи sshd:
sudo journalctl -u sshd -n 50 --no-pager

Шаг 5. Подробный вывод SSH-клиента

# Режим verbose: показывает весь процесс подключения
ssh -v user@server

# Максимально подробный вывод
ssh -vvv user@server

Что искать в выводе -v:

• Connection refused — порт закрыт или sshd не запущен
• Connection timed out — firewall блокирует пакеты
• No route to host — проблема сети/маршрутизации
• Permission denied (publickey) — проблема с ключом
• Permission denied (password) — неверный пароль или отключена парольная аутентификация
• Too many authentication failures — исчерпаны попытки аутентификации

Шаг 6. Проблема с SSH-ключом

# Проверить права (критично!)
ls -la ~/.ssh/
# ~/.ssh/          должно быть 700
# ~/.ssh/id_rsa    должно быть 600
# ~/.ssh/id_rsa.pub должно быть 644

# Исправить если неверные:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

# Убедиться что публичный ключ добавлен на сервере
cat ~/.ssh/id_rsa.pub
# Этот ключ должен быть в /home/user/.ssh/authorized_keys на сервере

# На сервере проверить authorized_keys
ls -la ~/.ssh/authorized_keys
# Должно быть 600
chmod 600 ~/.ssh/authorized_keys

# Проверить содержимое
cat ~/.ssh/authorized_keys

Шаг 7. Fail2Ban заблокировал IP

# Проверить статус Fail2Ban на сервере
sudo fail2ban-client status
sudo fail2ban-client status sshd

# Посмотреть заблокированные IP
sudo fail2ban-client status sshd | grep 'Banned IP'

# Разблокировать свой IP
sudo fail2ban-client set sshd unbanip YOUR_IP

Шаг 8. Пользователь не может войти

# Пользователь существует?
getent passwd username

# Аккаунт заблокирован?
sudo passwd -S username
# L = locked, P = password set, NP = no password

# Разблокировать:
sudo usermod -U username
# или
sudo passwd -u username

# Пользователь в AllowUsers в sshd_config?
grep -i 'allowusers\|allowgroups\|denyusers' /etc/ssh/sshd_config

Если доступа нет совсем: экстренный вариант

# Через консоль провайдера:
# 1. Проверить sshd
systemctl restart sshd

# 2. Временно разрешить пароль в /etc/ssh/sshd_config
# PasswordAuthentication yes
# systemctl reload sshd

# 3. Проверить UFW
ufw allow 22/tcp

Итог

90% случаев — это один из первых четырёх шагов: порт закрыт, firewall блокирует, sshd не запущен или Fail2Ban заблокировал IP. Режим ssh -v в большинстве случаев сразу указывает на слой проблемы.