FixPedia
Linux

SSH не подключается: полное руководство по диагностике и решению

Этот гайд предоставляет системный подход к диагностике и устранению распространённых проблем с SSH-подключениями в Linux. Вы научитесь проверять сетевую доступность, настройки демона, аутентификацию и брандмауэр, чтобы быстро восстановить доступ к удалённым серверам.

Обновлено 16 февраля 2026 г.
15-30 мин
Средняя
FixPedia Team
Применимо к:Ubuntu 22.04+CentOS 7/8Debian 11+Any Linux with OpenSSH

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

Подключение к удалённому серверу по SSH — это основа ежедневной работы системного администратора, DevOps-инженера и разработчика. Когда подключение не удаётся, работа останавливается. Ошибки SSH часто имеют схожие причины: сетевая недоступность, неверные настройки демона, проблемы с аутентификацией или блокировка брандмауэром. Этот гайд предлагает структурированный, пошаговый подход к диагностике, который поможет вам быстро найти и устранить корень проблемы, а не просто "перезапустить сервис и надеяться".

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

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

Перед началом диагностики убедитесь, что у вас есть:

  1. Доступ к консоли сервера (KVM, IPMI, виртуальная консоль в панели управления хостинг-провайдера). Это критически важно, если проблема заблокировала ваш основной SSH-доступ.
  2. Права суперпользователя (sudo) на целевом сервере для проверки логов, конфигурации и управления брандмауэром.
  3. Клиентская машина с установленным OpenSSH-клиентом (ssh, scp, ssh-keygen).
  4. Базовые знания о работе сетевых команд (ping, nc, ss) и структуре файловых прав в Linux.

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

Первым делом нужно понять, доходит ли ваш сетевой пакет до сервера и слушает ли сервер нужный порт (по умолчанию 22).

  1. Проверьте доступность хоста:
    ping <IP_адрес_или_домен_сервера>

    Если ping не проходит, проблема на сетевом уровне (маршрутизация, firewall на промежуточном узле, сервер выключен).
  2. Проверьте, слушает ли SSH-демон порт и открыт ли он снаружи: На сервере (через консоль) выполните:
    # Посмотреть, какой порт слушает sshd и на каком интерфейсе
sudo ss -tlnp | grep :22
# Или
sudo netstat -tlnp | grep :22

    Ожидаемый результат: 0.0.0.0:22 или :::22 (слушает на всех интерфейсах). Если 127.0.0.1:22 — демон слушает только localhost, и нужно править sshd_config.
    С клиента попробуйте проверить открытость порта с помощью nc (netcat):
    nc -zv <IP_адрес_сервера> 22

    Успешный результат: Connection to <IP> 22 port [tcp/ssh] succeeded!. Если Connection refused — порт закрыт (демон не слушает или блокируется брандмауэром). Если Operation timed out — пакеты теряются (брандмауэр сбрасывает соединение или проблема с маршрутизацией).

⚠️ Важно: Некоторые облачные провайдеры (AWS, GCP, DigitalOcean) используют Security Groups / Firewall Rules на уровне гипервизора. Убедитесь, что правила там разрешают входящий трафик на порт 22/TCP с вашего IP-адреса.

Шаг 2: Анализ логов SSH-демона на сервере

Логи — самый ценный источник информации. Подключитесь к консоли сервера и проверьте системный журнал.

  • Для Debian/Ubuntu:
    sudo tail -f /var/log/auth.log
  • Для RHEL/CentOS/Rocky/AlmaLinux:
    sudo tail -f /var/log/secure

Теперь, с клиента, попробуйте выполнить неудачное подключение. Наблюдайте за логами в реальном времени. Типичные записи и их значение:

  • Failed password for <user> from <client_ip> port <port> ssh2 — неверный пароль (если парольная аутентификация включена).
  • Invalid user <user> from <client_ip> — попытка логина под несуществующим пользователем.
  • Connection closed by <client_ip> port <port> [preauth] — клиент разорвал соединение до аутентификации (часто из-за несовпадения ключей или таймаута).
  • Authentication failed. — общая ошибка аутентификации (ключ, пароль, GSSAPI).
  • POSSIBLE BREAK-IN ATTEMPT! — слишком много неудачных попыток, демон может временно заблокировать IP (если настроены MaxAuthTries или fail2ban).

Что искать: точное время попытки, IP-адрес клиента, имя пользователя и конкретную строку с ошибкой.

Шаг 3: Валидация конфигурации SSH-демона и прав доступа

Неправильные настройки в /etc/ssh/sshd_config или права на файлы — частая причина отказа в доступе.

  1. Проверьте основной конфиг:
    sudo cat /etc/ssh/sshd_config | grep -E "^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AllowUsers|DenyUsers)"

    Ключевые параметры:
    • PasswordAuthentication — yes или no. Если no, нужен работающий публичный ключ.
    • PubkeyAuthentication — должен быть yes для работы с ключами.
    • PermitRootLogin — prohibit-password (разрешает только ключевую), yes или no.
    • AllowUsers / AllowGroups — если указаны, только перечисленные пользователи/группы могут подключаться.
    • Port — нестандартный порт (если изменён, подключайтесь через него: ssh -p <port> user@host).

    После любых изменений перезапустите демон:
    sudo systemctl restart sshd
# Или для старого sysvinit:
# sudo service ssh restart
  2. Проверьте права на файлы пользователя на сервере: SSH-демон очень строг к правам. Подключитесь к консоли и проверьте для целевого пользователя (например, ubuntu):
    # Права на домашнюю директорию
ls -ld /home/ubuntu
# Ожидается: drwxr-xr-x (755) или drwx------ (700). НЕ должно быть записи для группы и других (например, 777).

# Права на папку .ssh
ls -ld /home/ubuntu/.ssh
# Ожидается: drwx------ (700)

# Права на файл authorized_keys
ls -l /home/ubuntu/.ssh/authorized_keys
# Ожидается: -rw------- (600)

    Если права шире, исправьте:
    sudo chmod 700 /home/ubuntu/.ssh
sudo chmod 600 /home/ubuntu/.ssh/authorized_keys
sudo chown -R ubuntu:ubuntu /home/ubuntu/.ssh

Шаг 4: Проверка правил брандмауэра и SELinux/AppArmor

Брандмауэр на сервере может блокировать входящие соединения на порт 22.

  1. Проверьте активные правила:
    • firewalld (RHEL/CentOS 7+, Fedora): 
      sudo firewall-cmd --list-all
      В выводе в секции services: или ports: должна быть строка ssh или 22/tcp. Если нет, добавьте: 
      sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
    • ufw (Ubuntu/Debian по умолчанию): 
      sudo ufw status verbose
      Должна быть строка 22/tcp (SSH) ALLOW IN. Если нет: 
      sudo ufw allow ssh
sudo ufw reload
    • iptables (legacy): 
      sudo iptables -L INPUT -n -v | grep 22
      Ищите правило с ACCEPT для порта 22. Если правил нет или стоит DROP, добавьте: 
      sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Сохраните правила в зависимости от дистрибутива (iptables-save, netfilter-persistent)
  2. Проверьте SELinux (RHEL/CentOS/Fedora) или AppArmor (Ubuntu/Debian):
    • SELinux:
      getenforce
      Если Enforcing, проверьте контекст безопасности папки .ssh: 
      ls -laZ /home/ubuntu/.ssh
      Правильный контекст для домашней директории пользователя — unconfined_u:object_r:user_home_t:s0. Для authorized_keys — ssh_home_t. Если контекст неправильный, восстановите: 
      sudo restorecon -Rv /home/ubuntu/.ssh
    • AppArmor: Обычно не мешает SSH, но профиль может быть в режиме enforce. Проверьте: 
      sudo aa-status | grep ssh
      Если есть проблемы, попробуйте перевести профиль в complain-режим для теста: 
      sudo aa-complain /etc/apparmor.d/usr.sbin.sshd

Шаг 5: Диагностика клиентской стороны и ключей

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

  1. Убедитесь, что вы используете правильного пользователя и хост:
    # Базовая команда
ssh user@server_ip
# Если используется нестандартный порт
ssh -p 2222 user@server_ip
  2. Включите подробное логирование на клиенте:
    ssh -vvv user@server_ip

    Ключи -v (до трёх) покажут всю цепочку: попытку аутентификации по ключу, паролю, GSSAPI. Ищите строки debug1: Authentications that can continue: и debug1: Offering public key: .... Если ваш ключ не предлагается, проблема в его расположении или правах. Если предлагается, но сервер отказывает — смотрите логи сервера (Шаг 2).
  3. Проверьте права на локальные файлы ключей:
    ls -la ~/.ssh/

    Права на приватный ключ (например, id_rsa) должны быть 600 (-rw-------). На папку .ssh — 700. На публичный ключ (id_rsa.pub) — 644 допустим, но лучше 600.
  4. Убедитесь, что публичный ключ добавлен на сервер: На клиенте покажите содержимое публичного ключа:
    cat ~/.ssh/id_rsa.pub

    Скопируйте вывод и сравните с содержимым файла ~/.ssh/authorized_keys на сервере. Строка должна совпадать полностью (без лишних пробелов или переносов). Лучше всего перезаписать ключ на сервер:
    # На клиенте (копируем ключ в буфер обмена)
cat ~/.ssh/id_rsa.pub | xclip -selection clipboard  # для Linux с xclip
# Или просто откройте файл и скопируйте вручную.

# На сервере (через консоль)
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC..." >> /home/ubuntu/.ssh/authorized_keys
# Замените ... на реальную строку ключа. Убедитесь, что ключ добавляется с новой строки.
  5. Проверьте, не блокирует ли вас fail2ban или аналоги: Если вы многократно пытались подключиться с неверным паролем/ключом, IP мог быть заблокирован.
    sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip <ваш_клиентский_IP>

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

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

ssh user@server_ip

Если используется нестандартный порт, не забудьте флаг -p. Успешное подключение завершится приглашением командной строки сервера (user@server_ip:~$).

Критерии успеха:

  • Соединение установлено.
  • Вы видите приглашение оболочки (bash, zsh) удалённого сервера.
  • Никаких сообщений об ошибках Permission denied, Connection refused или Connection timed out.

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

  • ssh: connect to host ... port 22: Connection timed out
    • Причина: Сетевой пакет не доходит. Проверьте ping, маршрутизацию (traceroute), правила облачного Security Group и локального/промежуточного брандмауэра.
  • ssh: connect to host ... port 22: Connection refused
    • Причина: SSH-демон не слушает порт 22 на внешнем интерфейсе. Проверьте sshd_config (параметр ListenAddress) и убедитесь, что демон запущен (sudo systemctl status sshd).
  • Permission denied (publickey,password).
    • Причина: Аутентификация не прошла. Проверьте логи сервера (/var/log/auth.log). Убедитесь в правильности ключа, прав на ~/.ssh и authorized_keys, а также в том, что в sshd_config разрешён нужный метод (PubkeyAuthentication yes или PasswordAuthentication yes).
  • Received disconnect from ...: 2: Too many authentication failures
    • Причина: SSH-клиент предложил слишком много ключей (из ssh-agent или по умолчанию), и сервер отказал. Решение: явно указать ключ (ssh -i ~/.ssh/id_rsa user@host) или отключить агент для этого хоста в ~/.ssh/config: 
      Host your-server
    IdentitiesOnly yes
    IdentityFile ~/.ssh/id_rsa
  • WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
    • Причина: Изменился fingerprint хоста (сервер переустановлен, IP перешёл к другому владельцу). Не игнорируйте это предупреждение! Удалите старую запись из ~/.ssh/known_hosts (найдите строку с IP/доменом и удалите её) и подключитесь заново.

Дополнительные ресурсы

  • man sshd_config — официальная документация по конфигурационному файлу демона.
  • man ssh — документация по клиенту и его параметрам (-v, -i, -p).
  • man ssh-keygen — управление SSH-ключами (генерация, конвертация).
  • Документация OpenSSH: https://www.openssh.com/manual.html
  • Гайд по усилению безопасности SSH: /guides/linux/openssh-hardening
  • Устранение неполадок с firewall в Linux: /guides/linux/firewall-configuration

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

Что делать, если ssh выдает 'Permission denied (publickey)'?
Порт 22 закрыт, но я уверен, что демон sshd работает. В чём проблема?
Можно ли использовать SSH без пароля, но с ключом, если у меня нет прав суперпользователя на сервере?

Полезное

Проверка базовой сетевой доступности
Анализ логов SSH-демона на сервере
Валидация конфигурации SSH-демона и прав доступа
Проверка правил брандмауэра и SELinux/AppArmor
Диагностика клиентской стороны и ключей

Эта статья помогла вам решить проблему?