Debian/Ubuntu: как исправить Permission denied (publickey) из-за ~/.ssh, authorized_keys и прав на home directory

Ошибка Permission denied (publickey) в Debian и Ubuntu часто выглядит обманчиво: кажется, что сервер не видит ключ, клиент отправляет не тот файл или ключ повреждён. Но на практике одна из самых частых причин — неправильные права на домашний каталог пользователя, директорию ~/.ssh или файл authorized_keys.

Особенно часто это всплывает после ручного копирования файлов, восстановления из бэкапа, переноса аккаунта между серверами, использования scp или rsync от root, а также после неосторожного chmod -R по домашнему каталогу. В Debian и Ubuntu дополнительную роль играет настройка sshd под названием StrictModes: если она включена, OpenSSH проверяет владельца и права доступа к критичным путям и отклоняет вход при подозрительной конфигурации.

Разберём, какие права должны быть у home directory, ~/.ssh и authorized_keys, как быстро диагностировать проблему, как читать серверные логи и что делать в нестандартных случаях, когда всё вроде бы выставлено правильно, но доступ по ключу всё равно не работает.

Материал одинаково полезен и для обычных серверов, и для проектов на VDS, где SSH остаётся основным способом администрирования.

Сразу главный вывод: если вы видите Permission denied (publickey), не начинайте с перегенерации ключей. Сначала проверьте, куда именно смотрит сервер, кто владеет файлами и не блокирует ли вход проверка StrictModes.

Что именно проверяет OpenSSH при входе по ключу

Когда клиент подключается по SSH, он предлагает серверу один или несколько открытых ключей. Сервер сравнивает их с теми, что перечислены в authorized_keys для нужного пользователя. Но перед этим OpenSSH оценивает доверенность пути к этим файлам. Логика простая: если каталог или файл могут быть изменены посторонними, им нельзя доверять.

При включённом StrictModes сервер обычно проверяет несколько вещей:

• существует ли домашний каталог пользователя;
• принадлежит ли домашний каталог правильному пользователю и не имеет ли опасных прав;
• существует ли каталог ~/.ssh и кто его владелец;
• не доступен ли authorized_keys на запись тем, кому не следует;
• совпадает ли реальный путь с настройками AuthorizedKeysFile.

Из-за этого даже корректный публичный ключ в authorized_keys может быть проигнорирован. На клиенте вы увидите только общее Permission denied (publickey), а точная причина обычно находится в логах сервера.

Если сервер отклоняет ключ из-за прав, проблема почти всегда на стороне сервера, а не клиента. Самый быстрый путь — смотреть логи sshd и проверять права на целевой системе.

Эталонные права для home directory, ~/.ssh и authorized_keys

Для большинства обычных случаев в Debian и Ubuntu рабочая схема такая:

• домашний каталог пользователя: 755 или строже, например 750;
• каталог ~/.ssh: 700;
• файл ~/.ssh/authorized_keys: 600;
• владелец всех этих путей: сам пользователь, под которым выполняется вход.

Вокруг прав на home directory часто возникает путаница. Критично не само чтение для других пользователей, а возможность записи. То есть 755 обычно допустим, а вот 775 и тем более 777 — плохой вариант.

Для каталога ~/.ssh и файла authorized_keys требования строже. Здесь лучше не экспериментировать: 700 для каталога и 600 для файла — стандартная безопасная схема.

Быстрая проверка прав

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

getent passwd username
ls -ld /home/username
ls -ld /home/username/.ssh
ls -l /home/username/.ssh/authorized_keys
namei -l /home/username/.ssh/authorized_keys

Команда namei -l особенно полезна: она показывает права на каждом уровне пути. Нередко проблема находится не в самом authorized_keys, а в одном из родительских каталогов.

Как быстро исправить права без лишней магии

Если путь стандартный, а пользователь называется, например, alice, можно привести всё к каноничному виду такими командами:

chown alice:alice /home/alice
chmod 755 /home/alice
mkdir -p /home/alice/.ssh
chown alice:alice /home/alice/.ssh
chmod 700 /home/alice/.ssh
touch /home/alice/.ssh/authorized_keys
chown alice:alice /home/alice/.ssh/authorized_keys
chmod 600 /home/alice/.ssh/authorized_keys

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

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

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

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Как понять, что ломает именно StrictModes

В Debian и Ubuntu параметр StrictModes обычно включён по умолчанию. Проверить итоговую конфигурацию демона можно так:

sshd -T | grep -Ei 'strictmodes|authorizedkeysfile|pubkeyauthentication'

Если видите strictmodes yes, значит права действительно проверяются строго. Это нормальное и рекомендуемое поведение. Отключать его ради быстрого результата не стоит: так вы уберёте симптом, но оставите небезопасную конфигурацию.

Чаще всего проблема оказывается одной из этих:

• authorized_keys принадлежит root после копирования;
• ~/.ssh имеет права 755 или 775;
• домашний каталог пользователя доступен на запись группе;
• в цепочке пути есть каталог с небезопасными правами;
• используется нестандартный путь к AuthorizedKeysFile, а вы редактируете не тот файл.

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

Где смотреть логи в Debian/Ubuntu

Без логов разбор может затянуться. В современных Debian и Ubuntu удобнее всего использовать journalctl. Во время попытки входа откройте отдельную консоль и смотрите журнал в реальном времени:

journalctl -u ssh -f

На некоторых системах служба может называться sshd:

journalctl -u sshd -f

Если нужен более широкий поиск по журналу:

journalctl -xe | grep -i ssh

Также на части установок сообщения попадают в /var/log/auth.log:

tail -f /var/log/auth.log

Типичные сообщения, которые подсказывают причину:

• Authentication refused: bad ownership or modes for directory;
• Authentication refused: bad ownership or modes for file;
• Failed publickey for username;
• Could not open authorized keys;
• userauth_pubkey: key type ... not in PubkeyAcceptedAlgorithms.

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

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

Почему права могут быть правильными, а вход всё равно не работает

Типичная ситуация: вы выставили 700 и 600, владельцы совпадают, но вход по-прежнему не проходит. Тогда проверяйте не только права, но и сопутствующую конфигурацию.

Вы редактируете не тот authorized_keys

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

sshd -T | grep authorizedkeysfile

Если там указан путь, отличный от .ssh/authorized_keys, сервер читает другой файл. Это нередко встречается в кастомных образах и корпоративных шаблонах.

Неверный домашний каталог в passwd

Если у пользователя в системе прописан другой home directory, OpenSSH будет искать ключи там. Проверка простая:

getent passwd alice

Смотрите на шестое поле — путь к домашнему каталогу. Если он не совпадает с ожиданием, исправлять нужно не права, а запись пользователя.

Файл создан с Windows-переносами

Иногда authorized_keys выглядит нормально, но содержит окончания строк в формате CRLF. Тогда ключ может не распознаться корректно. Быстрая проверка:

sed -n 'l' /home/alice/.ssh/authorized_keys

Если видите хвосты \r, переведите файл в Unix-формат.

Сломан ownership после копирования от root

Классический сценарий: администратор копирует ключ от имени root, и файл получает владельца root:root. После любой административной операции полезно явно проверять chown.

ls -l /home/alice/.ssh/authorized_keys
chown alice:alice /home/alice/.ssh/authorized_keys

Если сервер только разворачивается, удобнее сразу закладывать резервный доступ и предсказуемые права на пользователей. Для этого подойдут как отдельные VDS, так и более простые сценарии на виртуальном хостинге — в зависимости от того, нужен ли вам полный контроль над SSH.

Как диагностировать проблему со стороны клиента

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

ssh -vvv alice@server

В выводе смотрите:

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

Если клиент вообще не отправляет нужный ключ, проблема уже не в authorized_keys, а, например, в конфигурации клиента, агенте, параметре IdentitiesOnly или неверном блоке Host в ~/.ssh/config.

Особенности home directory permissions

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

• чтение и выполнение для других пользователей могут быть допустимы, если это соответствует вашей модели доступа;
• запись для группы или остальных — почти всегда проблема;
• для SSH важнее всего, чтобы путь к authorized_keys не мог быть подменён посторонним.

Поэтому значения 755, 750 и 700 обычно допустимы, а 775 и 777 почти всегда ошибка. Если домашний каталог расположен в нестандартном месте, проверяйте и все родительские каталоги вплоть до mount point.

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

Для типовых проектов с ограниченным доступом по shell иногда достаточно виртуального хостинга, а для полной настройки SSH, пользователей и системных политик логичнее выбирать VDS.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Пошаговый чек-лист для восстановления входа

1. Подключитесь альтернативным способом: через консоль, rescue или другой админский аккаунт.
2. Проверьте, какой у пользователя домашний каталог через getent passwd.
3. Проверьте путь и права через ls -ld и namei -l.
4. Убедитесь, что владелец home directory, ~/.ssh и authorized_keys — нужный пользователь.
5. Выставьте права: 755 или строже для home, 700 для .ssh, 600 для authorized_keys.
6. Проверьте, что в sshd -T включён pubkeyauthentication и куда смотрит AuthorizedKeysFile.
7. Откройте journalctl -u ssh -f и повторите попытку входа.
8. Если ошибка осталась, сравните ключ на клиенте и содержимое authorized_keys, затем запустите ssh -vvv.

Чего не стоит делать

• Не ставьте 777 на домашний каталог или .ssh.
• Не отключайте StrictModes, пока не поняли первопричину.
• Не запускайте бездумно chmod -R 777 или chmod -R 755 по всему /home.
• Не забывайте проверять владельца файлов после копирования от root.
• Не редактируйте ключи вслепую, не сверившись с журналом и реальным путём из конфигурации.

Если вы администрируете несколько окружений, имеет смысл стандартизировать права, шаблоны пользователей и базовые проверки после развёртывания. Это особенно полезно на новых серверах и при миграции между хостингами, где меняется поведение образов и стартовых скриптов.

Готовый минимальный набор команд для типового случая

Если нужен короткий практический блок для типовой ситуации, вот безопасный минимум. Замените имя пользователя при необходимости:

USER=alice
HOME_DIR=$(getent passwd "$USER" | cut -d: -f6)
install -d -m 700 -o "$USER" -g "$USER" "$HOME_DIR/.ssh"
touch "$HOME_DIR/.ssh/authorized_keys"
chown "$USER:$USER" "$HOME_DIR/.ssh/authorized_keys"
chmod 600 "$HOME_DIR/.ssh/authorized_keys"
chown "$USER:$USER" "$HOME_DIR"
chmod 755 "$HOME_DIR"
namei -l "$HOME_DIR/.ssh/authorized_keys"
sshd -T | grep -Ei 'strictmodes|authorizedkeysfile|pubkeyauthentication'

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

journalctl -u ssh -f

Итог

В ошибке Permission denied (publickey) самое неприятное — её общность. Она не говорит, что именно пошло не так: неверный ключ, не тот пользователь, неправильный путь или небезопасные права. Но в Debian и Ubuntu очень большой процент таких случаев сводится к трём точкам: права на home directory, каталог .ssh и файл authorized_keys.

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

А если сервер только готовится к размещению проекта, лучше сразу держать под рукой резервный доступ и тестовый чек-лист после развёртывания.