Содержание статьи

Сообщение Access denied при подключении через PuTTY означает отказ сервера принять учётные данные или параметры сессии. Чаще всего причина лежит не на стороне клиента, а в настройках SSH на сервере: правах доступа к каталогам, владельцах файлов, политике аутентификации или сетевых ограничениях. Ошибка появляется сразу после ввода логина и ключа либо пароля, без установления полноценной сессии.
На практике отказ вызван конкретными проверками SSH: соответствие пользователя методу входа, корректность прав на ~/.ssh и authorized_keys, наличие пользователя в системе, разрешение входа в sshd_config. Даже один неверный бит прав или чужой владелец файла приводит к мгновенному отказу, что PuTTY показывает одной строкой без деталей.
Отдельный класс причин связан с защитными механизмами. Ограничения по IP в firewall, временные блокировки после неудачных попыток, политики SELinux или AppArmor могут разрывать соединение до передачи баннера. В таких случаях пароль и ключ корректны, но доступ закрыт правилами безопасности.
Разбор ошибки начинается с логов сервера: /var/log/auth.log или /var/log/secure. Они показывают точную причину отказа – от неверных прав на файлы до запрета входа по конфигурации. Дальнейшие шаги сводятся к проверке учётной записи, прав доступа и параметров SSH, что позволяет восстановить подключение без перебора настроек вслепую.
Проверка логина и метода аутентификации при подключении

Ошибка Access denied часто связана с указанием неверного логина. В PuTTY имя пользователя не передаётся автоматически, поэтому при подключении важно вводить именно системный логин, а не имя сервиса или отображаемое имя. На серверах Linux это обычно root, user или пользователь, созданный администратором. Наличие учётной записи можно проверить командой id username или просмотром файла /etc/passwd.
Следующий шаг – проверка разрешённого метода аутентификации. Если сервер настроен только на вход по SSH-ключу, попытка подключения с паролем всегда будет отклонена. В файле /etc/ssh/sshd_config параметр PasswordAuthentication должен соответствовать выбранному способу входа. При значении no сервер принимает исключительно ключи, даже если пароль введён корректно.
При использовании ключевой аутентификации в PuTTY необходимо убедиться, что выбран именно приватный ключ в формате .ppk. Ключи OpenSSH без конвертации через PuTTYgen сервером не распознаются клиентом, что приводит к отказу сразу после отправки данных. В настройках сессии путь к ключу задаётся в разделе Connection → SSH → Auth.
Дополнительно стоит учитывать ограничения для пользователя root. Во многих конфигурациях параметр PermitRootLogin установлен в значение no или prohibit-password, из-за чего прямой вход запрещён. В таких случаях требуется подключение под обычной учётной записью с последующим повышением прав через su или sudo.
Точную причину отказа показывает журнал аутентификации на сервере. Записи вида Invalid user, Authentication refused или Public key denied указывают, что проблема связана именно с логином или выбранным способом входа, а не с сетевыми настройками или правами доступа.
Исправление прав доступа к домашнему каталогу пользователя

При подключении по SSH сервер проверяет не только учётные данные, но и атрибуты домашнего каталога. Если каталог пользователя доступен на запись посторонним, соединение прерывается с ошибкой Access denied. Проверка выполняется командой stat /home/username или ls -ld /home/username, где важно обратить внимание на права и владельца.
Для корректной работы SSH допустимы права 750, 755 или 700. Наличие записи для группы или остальных пользователей считается нарушением безопасности. Исправление выполняется командой chmod 755 /home/username. Если доступ к каталогу должен быть закрыт для всех, кроме владельца, используется chmod 700.
Владелец и группа каталога обязаны совпадать с учётной записью пользователя. Ошибки часто появляются после миграции данных или распаковки архивов от имени root. В этом случае SSH фиксирует несоответствие и запрещает вход. Исправление выполняется командой chown username:username /home/username.
Отдельного внимания требуют родительские каталоги. Если /home или каталог выше имеют права на запись для всех, SSH также может отклонить соединение. Проверка выполняется рекурсивно вверх по пути, а допустимые значения для таких каталогов – 755 без флага записи для остальных.
После корректировки прав достаточно повторить подключение через PuTTY. Для подтверждения результата следует проверить журнал /var/log/auth.log, где ранее фиксировались сообщения о небезопасных правах на каталог пользователя.
Настройка прав на файл authorized_keys для SSH

При входе по ключу SSH проверяет файл ~/.ssh/authorized_keys до попытки аутентификации. Любое отклонение в правах или владельце приводит к отказу и сообщению Access denied. Проверка выполняется командой ls -l ~/.ssh/authorized_keys, где важны режим доступа и владелец.
Допустимые права для файла – 600. Наличие прав чтения или записи для группы и остальных пользователей блокирует вход. Исправление выполняется командой chmod 600 ~/.ssh/authorized_keys. Права 644 и выше считаются небезопасными и игнорируются сервером.
Каталог ~/.ssh также проходит проверку. Для него допустимы права 700. Если каталог доступен группе или всем, ключ не используется. Исправление выполняется командой chmod 700 ~/.ssh. Эти настройки применяются независимо от содержимого самого ключа.
Владелец файла и каталога обязан совпадать с пользователем, под которым выполняется вход. После копирования ключей от имени root часто остаётся неверный владелец, из-за чего SSH отклоняет аутентификацию. Проверка выполняется командой ls -ld ~/.ssh ~/.ssh/authorized_keys, исправление – chown -R username:username ~/.ssh.
Содержимое authorized_keys должно находиться в одной строке без переносов и лишних символов. Повреждённый или обрезанный ключ приводит к отказу без явного указания причины в PuTTY. Точную информацию можно получить из журнала /var/log/auth.log, где фиксируются сообщения о проблемах с ключами.
Проблемы с владельцем файлов и каталогов пользователя
Ошибка Access denied часто возникает, если файлы и каталоги пользователя имеют неверного владельца. Проверку можно выполнить командой ls -l /home/username, чтобы увидеть текущие права и владельца.
Для восстановления корректного владельца используйте команду chown -R username:username /home/username. Она рекурсивно назначает пользователя и группу владельцем всех файлов и подкаталогов.
После изменения владельца важно проверить, что authorized_keys и родительские каталоги имеют правильные права, иначе SSH продолжит блокировать доступ.
Рекомендуется избегать назначения владельцем root, так как это приводит к постоянным отказам в доступе при аутентификации ключами.
Запрет входа по SSH в настройках sshd_config
Ошибку Access denied может вызвать запрет входа в SSH для конкретного пользователя или группы в конфигурации sshd_config. Для проверки выполните следующие действия:
- Откройте файл /etc/ssh/sshd_config с помощью текстового редактора, например: sudo nano /etc/ssh/sshd_config.
- Проверьте параметры DenyUsers и DenyGroups. Если ваш пользователь указан здесь, доступ будет запрещен.
- Аналогично проверьте AllowUsers и AllowGroups. Если ваш пользователь не включен, вход невозможен.
После внесения изменений перезапустите SSH-сервис командой:
- sudo systemctl restart sshd
Важно сохранять правильные права на конфигурационный файл, чтобы SSH корректно считывал настройки и не блокировал авторизацию.
Ограничения входа по IP и правила firewall

Ошибка Access denied может возникать из-за ограничений на стороне сервера, связанных с IP-адресом клиента или настройками firewall. Первым шагом проверьте, разрешен ли ваш IP для подключения:
- Для проверки правил iptables используйте команду sudo iptables -L -n. Обратите внимание на цепочки INPUT и FORWARD с правилами ACCEPT или DROP для порта 22.
- В системах с firewalld выполните sudo firewall-cmd —list-all и убедитесь, что порт SSH открыт и зона соответствует вашему подключению.
Если IP заблокирован, добавьте правило разрешения доступа:
- Для iptables: sudo iptables -A INPUT -p tcp -s ваш_IP —dport 22 -j ACCEPT
- Для firewalld: sudo firewall-cmd —add-rich-rule=’rule family=»ipv4″ source address=»ваш_IP» port port=»22″ protocol=»tcp» accept’ —permanent
После изменения правил перезапустите firewall или примените их командой sudo systemctl reload firewalld для корректного вступления в силу.
Блокировка пользователя после неудачных попыток входа
Ошибка Access denied может быть вызвана автоматической блокировкой пользователя после многократных неверных попыток входа. В Linux это обычно контролируется через PAM-модуль pam_tally2 или faillock.
- Для проверки текущих блокировок выполните sudo faillock —user username или sudo pam_tally2 -u username.
- Если пользователь заблокирован, сбросьте счетчик попыток:
- Для pam_tally2: sudo pam_tally2 -u username -r
- Для faillock: sudo faillock —user username —reset
Рекомендуется проверить настройки в файле /etc/pam.d/sshd и параметры deny и unlock_time, чтобы определить порог блокировки и время разблокировки.
После сброса блокировки попробуйте подключение через PuTTY и убедитесь, что логин проходит без ограничений.
Ошибки SELinux и AppArmor при подключении по SSH
SELinux и AppArmor могут блокировать доступ к SSH, вызывая ошибку Access denied. Для диагностики необходимо проверить журналы безопасности и контексты безопасности файлов.
Примеры команд для проверки статуса и журналов:
| Система | Команда | Назначение |
|---|---|---|
| SELinux | sestatus | Проверка текущего режима (Enforcing/Permissive/Disabled) |
| SELinux | ausearch -m avc -ts recent | Поиск последних ошибок доступа |
| AppArmor | sudo aa-status | Проверка активных профилей и их режима |
| AppArmor | sudo dmesg | grep DENIED | Поиск заблокированных операций |
Для исправления проблем SELinux можно временно перевести режим в Permissive командой sudo setenforce 0. Для AppArmor – перевести профиль SSH в complain mode командой sudo aa-complain /etc/apparmor.d/usr.sbin.sshd. После внесения изменений рекомендуется протестировать подключение через PuTTY и вернуть политики в исходное состояние для безопасности.
Вопрос-ответ:
Почему при подключении через PuTTY появляется ошибка Access denied?
Ошибка Access denied возникает, когда сервер SSH отклоняет учетные данные пользователя. Основные причины: неверный логин, неправильный ключ SSH, некорректные права на домашний каталог или файл authorized_keys, блокировка пользователя после нескольких неудачных попыток или ограничения в конфигурации sshd_config.
Как проверить правильность логина и метода аутентификации в PuTTY?
Для проверки логина убедитесь, что указано правильное имя пользователя в поле Username. Если используется аутентификация по ключу, убедитесь, что выбран корректный приватный ключ в настройках PuTTY и что он соответствует публичному ключу на сервере. Также проверьте формат ключа: OpenSSH и PuTTY имеют разные форматы.
Каким образом исправить права доступа к домашнему каталогу и файлу authorized_keys?
На сервере выполните команду chmod 700 /home/username для домашнего каталога и chmod 600 /home/username/.ssh/authorized_keys для файла ключей. Убедитесь, что владелец установлен на пользователя: chown -R username:username /home/username. Некорректные права приводят к блокировке доступа даже при правильном логине.
Может ли firewall или настройки SSH блокировать доступ по IP?
Да, PuTTY может получать Access denied, если сервер ограничивает вход по IP или правила firewall запрещают подключение к порту 22. Для диагностики проверьте iptables или firewalld, убедитесь, что ваш IP разрешен. При необходимости добавьте правило для разрешения доступа и перезапустите сервис firewall.
