Исправляем SSH-подключения в Linux: диагностика и решение проблем

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

SSH (Secure Shell) — это стандартный протокол для безопасного удаленного управления серверами и сетевыми устройствами. Однако при работе с SSH на Linux могут возникать различные проблемы: от невозможности установить соединение до ошибок аутентификации. Этот гайд поможет вам системно диагностировать и решить типичные неполадки, чтобы восстановить рабочий SSH-доступ.

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

Перед началом убедитесь в следующем:

• У вас есть физический или альтернативный удаленный доступ к серверу (например, через консоль управления хостинг-провайдера), если SSH не работает.
• Вы знаете IP-адрес или доменное имя целевого сервера.
• На вашем клиентском компьютере установлен SSH-клиент (обычно openssh-client).
• Вы готовы использовать команды с sudo для выполнения административных задач.

Шаг 1: Проверка статуса SSH-демона

Первым делом убедитесь, что SSH-сервер (sshd) запущен на целевом сервере. Подключитесь к серверу через консоль (если возможно) или используйте альтернативный метод доступа.

Выполните команду:

sudo systemctl status sshd

Или на старых системах:

sudo service ssh status

Если служба не активна, запустите её:

sudo systemctl start sshd

Для автоматического запуска при загрузке:

sudo systemctl enable sshd

Шаг 2: Диагностика сетевого подключения и порта 22

Проверьте, доступен ли сервер по сети и открыт ли порт 22 (стандартный для SSH).

С клиентской машины выполните:

telnet <IP_сервера> 22

Или, если telnet не установлен:

nc -zv <IP_сервера> 22

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

Убедитесь, что SSH-демон слушает на всех интерфейсах. На сервере проверьте:

sudo ss -tlnp | grep :22

Должно быть что-то вроде: LISTEN 0 128 *:22 *:* users:(("sshd",pid=1234,fd=3)). Если слушает только 127.0.0.1, измените конфигурацию.

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

Ошибки в файле конфигурации /etc/ssh/sshd_config могут блокировать подключения. Проверьте этот файл на наличие опций, ограничивающих доступ.

Откройте файл:

sudo nano /etc/ssh/sshd_config

Или используйте vi/vim.

Обратите внимание на параметры:

• Port: если изменен со стандартного 22, убедитесь, что клиент подключается к правильному порту.
• PermitRootLogin: если установлено в no, то вход под root запрещен.
• AllowUsers или DenyUsers: проверьте, не ограничен ли доступ для вашего пользователя.
• PasswordAuthentication: если no, то требуется аутентификация по ключу.
• PubkeyAuthentication: должен быть yes для ключей.

После изменений перезапустите SSH:

sudo systemctl restart sshd

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

Логи SSH содержат подробную информацию об ошибках. Основные логи:

На Debian/Ubuntu:

sudo tail -f /var/log/auth.log

На CentOS/RHEL/Fedora:

sudo tail -f /var/log/secure

Попробуйте подключиться с клиента и одновременно смотрите логи. Ищите строки с "sshd" и сообщениями об ошибках, такие как "Failed password", "Connection closed", "Invalid user". Это укажет на причину.

Если логи пустые, возможно, соединение не доходит до SSH-демона из-за фаервола или сети.

Шаг 5: Проверка SSH-ключей и прав доступа

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

На клиенте проверьте наличие приватного ключа (обычно ~/.ssh/id_rsa или id_ed25519) и его права:

ls -la ~/.ssh/
chmod 600 ~/.ssh/id_rsa  # если ключ RSA
chmod 600 ~/.ssh/id_ed25519  # если ключ Ed25519

На сервере проверьте, что публичный ключ добавлен в ~/.ssh/authorized_keys для пользователя, и права:

ls -la ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Каталог ~/.ssh должен иметь права 700.

Если ключи не работают, пересоздайте пару и скопируйте публичный ключ с помощью ssh-copy-id:

ssh-copy-id user@server

Шаг 6: Настройка фаервола

Фаервол на сервере может блокировать порт 22. Проверьте активные правила.

Для ufw (Ubuntu/Debian):

sudo ufw status

Если SSH не разрешен, добавьте:

sudo ufw allow 22

Или для конкретного порта, если изменен.

Для firewalld (CentOS/RHEL/Fedora):

sudo firewall-cmd --list-all

Разрешите SSH:

sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload

Для iptables (более старые системы):

sudo iptables -L -n

Добавьте правило, если нужно.

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

После выполнения шагов попробуйте подключиться с клиента:

ssh user@server

Если используется нестандартный порт:

ssh -p <порт> user@server

Успешное подключение с приглашением командной строки или без запроса пароля (при ключевой аутентификации) указывает на решение проблемы.

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

При выполнении гайда могут возникнуть дополнительные сложности:

• Ошибка "Connection timed out": Проверьте, доступен ли сервер по сети (ping, traceroute), и что нет блокировки на промежуточных маршрутизаторах.
• Ошибка "Host key verification failed": Это может означать изменение ключа хоста на сервере. Удалите запись для сервера из ~/.ssh/known_hosts на клиенте и попробуйте снова.
• Проблемы с SELinux (на CentOS/RHEL): Если SELinux в режиме enforcing, он может блокировать SSH. Проверьте логи SELinux (ausearch -m avc -ts recent) и настройте политики.
• Недостаток ресурсов на сервере: Если сервер перегружен, SSH-демон может не отвечать. Проверьте использование CPU и памяти (top, htop).

Этот список не исчерпывающий; используйте логи и диагностические команды для дальнейшего анализа.