Ошибка «Permission Denied» при подключении по SSH: руководство по устранению

SSH (Secure Shell) — это основной протокол для безопасного удаленного управления серверами, сетевыми устройствами и другими хостами. Он обеспечивает зашифрованное соединение, защищая передаваемые данные с помощью пары ключей (открытого и закрытого) или пароля.

При попытке подключения по SSH вы можете столкнуться с распространенной и неприятной ошибкой: Permission denied (publickey). В этой статье мы подробно разберем основные причины этой ошибки и предоставим пошаговые инструкции по её устранению.

Основные причины ошибки Permission Denied

Ошибка «Permission denied» при использовании аутентификации по ключу (publickey) указывает, что SSH-демон на сервере не смог подтвердить вашу личность. Это может произойти по нескольким ключевым причинам:

• Неправильные права доступа (permissions) или владелец для файлов ключей (id_rsa, authorized_keys) или каталога .ssh.
• Неверная конфигурация SSH-демона (sshd) на сервере (например, отключена аутентификация по паролю или ключам).
• Отсутствие или неправильный открытый ключ в файле ~/.ssh/authorized_keys на сервере.
• Неправильный вызов SSH-клиента (использование не того ключа, который ожидает сервер).

Шаг 1: Проверка и исправление прав доступа к ключам и каталогу

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

На удаленном сервере (где находится файл authorized_keys)

Файл ~/.ssh/authorized_keys содержит открытые ключи тех клиентских систем, которым разрешен доступ. Права доступа к этому файлу и каталогу .ssh должны быть максимально строгими:

Если вы можете войти на сервер другим способом (например, через консоль хостинга или по паролю, если он временно включен), выполните следующие команды:

# Устанавливаем владельца (если это необходимо, обычно $USER)
$ sudo chown -R $USER:$USER ~/.ssh

# Проверяем права на каталог .ssh и устанавливаем 700
$ chmod 700 ~/.ssh

# Проверяем права на файл authorized_keys и устанавливаем 600
$ chmod 600 ~/.ssh/authorized_keys

На клиентской машине (где находятся ваши ключи)

Закрытый ключ — это самый важный файл, и он должен быть защищен.

• Закрытый ключ (id_rsa, id_ed25519 и т.д.) должен иметь права 600 (только чтение/запись для владельца).
• Открытый ключ (id_rsa.pub) может иметь права 644.

# Для закрытого ключа: только владелец может читать и писать
$ chmod 600 ~/.ssh/id_rsa

# Для открытого ключа: владелец может читать/писать, остальные только читать
$ chmod 644 ~/.ssh/id_rsa.pub

Шаг 2: Включение аутентификации по паролю (как запасной вариант)

Аутентификация по ключу всегда предпочтительнее с точки зрения безопасности. Однако, если вы потеряли доступ к своему приватному ключу или столкнулись с ошибкой в настройке, временное включение аутентификации по паролю может стать вашим спасательным кругом для входа на сервер и исправления настроек ключей.

⚠️Важно: После устранения проблемы с ключами настоятельно рекомендуется снова отключить аутентификацию по паролю для повышения безопасности.

• Отредактируйте файл конфигурации SSH-демона на сервере:

sudo nano /etc/ssh/sshd_config

• Найдите и измените следующие параметры, чтобы разрешить вход по паролю:

# Чтобы отключить туннелирование паролей в открытом виде, измените значение на 'no'!
PasswordAuthentication yes

# Рекомендуется оставить 'no' для повышения безопасности, 
# но можно временно включить, если нужно решить проблему с пустым паролем.
PermitEmptyPasswords no

• Перезапустите службу SSH-демона:

sudo systemctl restart sshd

• Попробуйте войти снова. Теперь сервер должен запросить у вас пароль:

ssh user@10.179.254.41
user@10.179.254.41's password: 
# Введите пароль и, если все верно, вы войдете

Шаг 3: Проверка логов SSH-демона для точной диагностики

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

На сервере выполните команду для просмотра последних записей в журнале, связанных с SSH:

# Для систем с systemd (Ubuntu, Debian, CentOS, Fedora)
sudo journalctl -u sshd -n 50 --no-pager

Ищите строки, содержащие authentication failure или Permission denied. Они могут указать на конкретную проблему, например:

• Authentication refused: bad ownership or modes for directory /home/user (Неправильный владелец или права для домашнего каталога).
• Authentication refused: key not registered (Ключ не найден в authorized_keys).
• User user not allowed because not listed in AllowUsers (Пользователю запрещено входить по настройкам sshd_config).

Шаг 4: Дополнительная проверка конфигурации

Иногда ошибка может быть вызвана специфическими настройками в файле /etc/ssh/sshd_config:

• Проверка пользователя: Убедитесь, что ваш пользователь не запрещен в настройках. Проверьте параметры DenyUsers, AllowUsers, DenyGroups и AllowGroups.
• Включение аутентификации по ключу: Убедитесь, что параметр PubkeyAuthentication установлен в yes.

PubkeyAuthentication yes

• Путь к ключам: Убедитесь, что параметр AuthorizedKeysFile указывает на правильный путь (по умолчанию это .ssh/authorized_keys относительно домашнего каталога пользователя).

Заключение.

Ошибка Permission denied (publickey) при подключении по SSH почти всегда связана с недостаточно строгими правами доступа к ключам и каталогу .ssh или проблемами с конфигурацией sshd_config на сервере.

Если вы выполнили Шаг 1 (исправление прав доступа) и Шаг 4 (проверка конфигурации) и проблема не решилась, Шаг 3 (проверка логов) — это единственный способ получить однозначный ответ.

Используйте аутентификацию по SSH-ключам как основной и самый безопасный способ доступа к вашим серверам!

Читайте также

• OpenSSH: руководство по установке, настройке и обеспечении безопасности
• Атрибуты файлов в Linux
• Linux Scheduler: Автоматизация задач с Cron и Systemd Timers
• Linux Permissions
• Управление процессами в Linux