Решение ошибки SSH Permission denied в Linux: подробное руководство

Введение

Ошибка SSH Permission denied возникает при попытке подключиться к Linux-серверу по SSH, когда сервер отказывает в доступе из-за проблем с аутентификацией или правами. Этот гайд поможет вам диагностировать и решить проблему, восстановив безопасный доступ к серверу. Вы научитесь проверять права доступа, настраивать SSH-демон и анализировать логи.

Требования

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

• Доступ к серверу через консоль (KVM, IPMI) или альтернативный метод, если SSH недоступен.
• Права суперпользователя (sudo) для изменения системных файлов и перезапуска служб.
• Базовые знания Linux: работа с командной строкой, редактирование файлов (например, через nano или vim).
• Клиент SSH на локальной машине (обычно OpenSSH).

Пошаговая инструкция

Шаг 1: Проверьте права доступа к файлам SSH

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

ls -la ~/.ssh

Пример вывода для правильных прав:

drwx------ 2 user user 4096 Feb 16 12:00 .
drwxr-xr-x 5 user user 4096 Feb 16 12:00 ..
-rw------- 1 user user  400 Feb 16 12:00 authorized_keys

Если права отличаются, исправьте их:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R user:user ~/.ssh  # замените user на имя пользователя для входа

💡 Совет: Для пользователя root проверьте /root/.ssh, а не домашнюю директорию обычного пользователя.

Шаг 2: Настройте конфигурацию SSH сервера

Убедитесь, что SSH-демон (sshd) настроен правильно. Отредактируйте файл конфигурации:

sudo nano /etc/ssh/sshd_config

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

PubkeyAuthentication yes
PasswordAuthentication yes  # временно включите для отладки, затем отключите
PermitRootLogin no         # запретите вход под root для безопасности
StrictModes yes            # должно быть yes для проверки прав

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

sudo systemctl restart sshd    # для systemd (Ubuntu 22.04, CentOS 8, Debian 11)
# или
sudo service ssh restart      # для SysV init

Шаг 3: Проверьте SELinux или AppArmor

Системы с SELinux (CentOS, RHEL, Fedora) или AppArmor (Ubuntu, Debian) могут блокировать доступ из-за политик безопасности.

Для SELinux:

getenforce  # если вывод "Enforcing", проверьте контекст
ls -Z ~/.ssh

Если контекст не ssh_home_t или ssh_home_dir_t, исправьте:

restorecon -R ~/.ssh

Для AppArmor: Обычно не влияет на SSH, но проверьте профили:

sudo aa-status | grep ssh

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

Шаг 4: Убедитесь в правильности аутентификации

Для аутентификации по публичному ключу:

• На клиенте убедитесь, что приватный ключ существует (~/.ssh/id_rsa или id_ed25519).
• Скопируйте публичный ключ на сервер, если ещё не сделано:

  ssh-copy-id user@host
  

  Или вручную:

  cat ~/.ssh/id_rsa.pub | ssh user@host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
  

• Проверьте, что в ~/.ssh/authorized_keys одна строка с ключом, без лишних символов.

Для аутентификации по паролю:

• Убедитесь, что PasswordAuthentication yes в sshd_config.
• Проверьте, что пользователь имеет пароль: passwd user.

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

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

ssh -v user@host

Если нужно указать ключ или порт:

ssh -i ~/.ssh/id_rsa -p 2222 -v user@host

В выводе ищите строки с debug1: и Permission denied. Обычно ошибка происходит на этапе Authenticating with public key или password. Это укажет, какой метод аутентификации не сработал.

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

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

ssh user@host

Если подключение успешно, вы увидите приглашение командной строки сервера. Если ошибка persists:

• Проверьте логи в реальном времени:

  sudo tail -f /var/log/auth.log        # Ubuntu/Debian
  sudo journalctl -u sshd -f            # systemd (CentOS 8, Ubuntu 22.04)
  

• Ищите записи с Failed или Permission denied — они укажут точную причину.

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

• "Bad owner or permissions on ~/.ssh/authorized_keys": Установите права 600 на файл и 700 на директорию.
• "Authentication refused: bad ownership or modes for directory /home/user": Проверьте права на домашнюю директорию пользователя: chmod 755 /home/user (не должна быть доступна на запись другим).
• Ошибка при использовании нестандартного порта: Убедитесь, что порт открыт в брандмауэре (sudo ufw allow 2222 для Ubuntu) и указан в команде ssh -p.
• Ключ не загружается в ssh-agent: Если используете агент, добавьте ключ: ssh-add ~/.ssh/id_rsa.
• SELinux в enforcing блокирует доступ: Временно отключите для теста: sudo setenforce 0, но затем настройте контекст правильно.
• Проблемы с DNS или hosts.allow/hosts.deny: Проверьте, не блокирует ли доступ hosts.deny или firewall.

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