SSH Permission denied: причины и быстрые решения для Linux

Что означает ошибка Permission denied

Ошибка SSH Permission denied (доступ запрещён) появляется, когда SSH-демон (sshd) на целевом сервере отказывает в аутентификации. Сообщение может выглядеть так:

Permission denied (publickey,password).

Или, если используется конкретный метод:

Permission denied (publickey).

Ошибка возникает на этапе аутентификации, то есть соединение установлено, но сервер не пропускает пользователя. Это не сетевой сбой (в отличие от Connection refused), а проблема с учетными данными или настройками безопасности.

Причины возникновения

1. Неверные учетные данные — ошибочный логин, пароль или использование не того приватного ключа.
2. Неправильные права на файлы ~/.ssh — на сервере папка .ssh или файл authorized_keys должны иметь строгие права (700 и 600 соответственно) и принадлежать целевому пользователю.
3. Отключенные методы аутентификации в sshd_config — например, PasswordAuthentication no при попытке входа по паролю.
4. Пользователь заблокирован или не имеет оболочки — в /etc/passwd у пользователя стоит /usr/sbin/nologin или /bin/false.
5. SELinux/AppArmor — контекст безопасности мешает доступу к ~/.ssh.
6. Блокировка по IP — через fail2ban, denyhosts или hosts.deny.
7. Несоответствие ключей — публичный ключ на сервере не соответствует приватному на клиенте.
8. Ограничения в sshd_config — AllowUsers, DenyUsers, AllowGroups, DenyGroups исключают пользователя.
9. Проблемы с хост-ключами — хотя обычно это вызывает другое предупреждение, иногда может влиять на аутентификацию.

Способ 1: Проверка учетных данных и базовые шаги

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

1. Укажите пользователя явно в команде:

   ssh -l username server_ip
   

   
   или

   ssh username@server_ip
   

2. При использовании ключа проверьте, что приватный ключ загружен в ssh-agent:

   ssh-add -l
   

   
   Если список пуст, добавьте ключ:

   ssh-add ~/.ssh/id_rsa
   

   
   Или укажите ключ напрямую:

   ssh -i ~/.ssh/id_rsa username@server_ip
   

3. При использовании пароля убедитесь, что пароль верный и для учетной записи не установлены ограничения (например, срок действия пароля истек).
4. Проверьте, доступен ли сервер (сетевой层面的):

   ping server_ip
   nc -zv server_ip 22
   

💡 Совет: Если вы не уверены, какой метод аутентификации используется, попробуйте явно указать -o PubkeyAuthentication=no для пароля или -o PreferredAuthentications=publickey для ключа.

Способ 2: Исправление прав на файлы .ssh на сервере

Неправильные права — самая частая причина. Подключитесь к серверу через консоль (если есть физический доступ) или используйте альтернативный метод (например, через веб-консоль облачного провайдера).

1. Войдите на сервер под учетной записью, к которой пытаетесь подключиться по SSH (или под root).
2. Проверьте текущие права:

   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
   

3. Исправьте права:

   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys
   chown -R $(whoami):$(whoami) ~/.ssh
   

4. Для SELinux (если используется):

   restorecon -Rv ~/.ssh
   

5. Перезапустите SSH-демон:

   sudo systemctl restart sshd
   

Способ 3: Проверка и настройка sshd_config

Конфигурационный файл sshd_config может блокировать аутентификацию.

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

   sudo nano /etc/ssh/sshd_config
   

   
   или

   sudo vi /etc/ssh/sshd_config
   

2. Убедитесь, что строки имеют правильные значения:

   PubkeyAuthentication yes
   PasswordAuthentication yes   # если используете пароль
   PermitRootLogin no           # или prohibit-password, но не yes для безопасности
   ChallengeResponseAuthentication no
   UsePAM yes
   

3. Проверьте директивы доступа:
   • Если есть AllowUsers или AllowGroups, убедитесь, что ваш пользователь указан.
   • Если есть DenyUsers или DenyGroups, убедитесь, что ваш пользователь не в списке.
4. Перезагрузите конфигурацию:

   sudo systemctl restart sshd
   

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

   sudo sshd -t
   

5. Если меняли порт (через Port), убедитесь, что подключаетесь к правильному порту:

   ssh -p 2222 username@server_ip
   

Способ 4: Анализ логов SSH

Логи содержат точную причину отказа.

1. На сервере просмотрите логи в реальном времени при попытке подключения:
   • Ubuntu/Debian:

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

   • RHEL/CentOS/Fedora:

     sudo tail -f /var/log/secure
     

2. Типичные записи:
   • Failed publickey for username from client_ip port ...: проблема с ключом.
   • Failed password for username from client_ip port ...: неверный пароль или парольная аутентификация отключена.
   • User username not allowed because not listed in AllowUsers: ограничение в конфиге.
   • User username not allowed because shell /usr/sbin/nologin not listed in /etc/shells: оболочка запрещена.
3. Используйте grep для фильтрации:

   sudo grep "sshd.*Failed" /var/log/auth.log
   

Способ 5: Проверка блокировок и SELinux/AppArmor

Проверка блокировок по IP

1. Проверьте fail2ban (если установлен):

   sudo fail2ban-client status sshd
   

   
   Если ваш IP в списке, разблокируйте:

   sudo fail2ban-client set sshd unbanip client_ip
   

2. Проверьте hosts.deny:

   cat /etc/hosts.deny
   

   
   Если есть строка sshd: ALL или sshd: client_ip, удалите её или добавьте исключение в hosts.allow.
3. Проверьте iptables/nftables:

   sudo iptables -L -n | grep 22
   sudo nft list ruleset | grep 22
   

Проверка SELinux (RHEL/CentOS/Fedora)

1. Проверьте статус:

   sestatus
   

   
   Если Enabled, проверьте контекст ~/.ssh:

   ls -laZ ~/.ssh
   

   
   Должен быть ssh_home_t для файлов и ssh_home_dir_t для папки.
2. Восстановите контекст:

   sudo restorecon -Rv ~/.ssh
   

3. Если проблема persists, временно отключите SELinux для диагностики:

   sudo setenforce 0
   

   
   Но не оставляйте его отключённым! После диагностики найдите правильное решение (правильный контекст или политику).

Проверка AppArmor (Ubuntu/Debian)

1. Проверьте профиль sshd:

   sudo aa-status | grep sshd
   

   
   Если профиль в режиме enforce, попробуйте перевести в complain:

   sudo aa-complain /etc/apparmor.d/usr.sbin.sshd
   

   
   Перезапустите sshd и проверьте подключение.
2. Если работает, настройте профиль правильно или оставьте в complain, если нет угроз.

Способ 6: Проверка оболочки и состояния пользователя

1. Убедитесь, что у пользователя есть оболочка:

   grep ^username: /etc/passwd
   

   
   Последнее поле должно быть /bin/bash, /bin/sh или другой допустимой оболочкой из /etc/shells. Если /usr/sbin/nologin или /bin/false, измените:

   sudo chsh -s /bin/bash username
   

2. Проверьте, не заблокирован ли пользователь:

   sudo passwd -S username
   

   
   Если статус L (locked), разблокируйте:

   sudo passwd -u username
   

3. Проверьте, не истек ли пароль:

   sudo chage -l username
   

   
   Если пароль истек (Password expires), сбросьте:

   sudo passwd username
   

Профилактика

• Используйте SSH-ключи вместо паролей — они надежнее и удобнее.
• Регулярно обновляйте OpenSSH для получения исправлений уязвимостей:

  sudo apt update && sudo apt upgrade openssh-server   # Debian/Ubuntu
  sudo yum update openssh-server                       # RHEL/CentOS 7
  sudo dnf update openssh-server                       # RHEL/CentOS 8+/Fedora
  

• Настройте sshd_config безопасно: отключите PasswordAuthentication, если используете ключи; ограничьте доступ через AllowUsers.
• Мониторьте логи (/var/log/auth.log или /var/log/secure) на предмет подозрительных попыток.
• Используйте фаервол (ufw, firewalld, iptables) для ограничения порта 22 только доверенными IP.
• Не используйте root-доступ напрямую — подключайтесь под обычным пользователем и повышайте права через sudo.
• Регулярно проверяйте права на ~/.ssh и authorized_keys после изменений в системе.
• При использовании SELinux/AppArmor не отключайте их, а настраивайте политики корректно.

Если проблема не решена, проверьте сетевые настройки (NAT, облачные security groups) и аутентификацию через PAM (/etc/pam.d/sshd). В крайнем случае временно увеличьте уровень логирования в sshd_config (LogLevel VERBOSE) и перезапустите sshd для получения деталей.