Alpine: SSH не принимает ключ из-за прав на файлы

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

Вход по SSH-ключу в Alpine не работает, если права на домашний каталог, ~/.ssh или authorized_keys слишком открыты: OpenSSH (параметр StrictModes yes) молча отклоняет ключ. В журнале при этом написано Authentication refused: bad ownership or modes for directory.

Правильные права: домашний каталог не открыт на запись группе и другим, .ssh — 700, authorized_keys — 600.

Владелец — пользователь.

OpenSSH отказывается использовать ключи с широкими правами. Закрытый ключ должен быть доступен только владельцу (600), а каталог .ssh — 700.

#Причины и решения

#Пошаговое решение

1. Проверьте права на ~, ~/.ssh, authorized_keysВ терминале сервера выполните ls -ld ПУТЬ_К_КАТАЛОГУ и ls -l ПУТЬ_К_ФАЙЛУ, подставив пути из сообщения об ошибке. В выводе посмотрите владельца, группу и разрешения. Затем уточните, от какого пользователя работает служба (systemctl show ИМЯ_СЛУЖБЫ -p User для службы systemd). Изменяйте владельца или права только после определения правильного значения; не выставляйте 777 ради обхода ошибки.
2. Установите 700 и 600Для SSH сначала определите учётную запись и каталог: ls -ld ~/.ssh и ls -l ~/.ssh/authorized_keys. Права для собственной учётной записи: chmod 700 ~/.ssh и chmod 600 ~/.ssh/authorized_keys, если каталог и файл принадлежат вам. На сервере проверьте sshd -t от root перед перезапуском SSH, не закрывая действующую сессию. Не публикуйте содержимое приватного ключа.

   Linux · Терминал (Bash)С осторожностьюКопировать всёВыделить

   Изменение прав ~/.ssh и authorized_keys может заблокировать удалённый вход; проверьте владельца и обеспечьте запасной доступ.

   chmod 700 ~/.ssh

   chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

3. Проверьте формат ключаПроверьте содержимое ~/.ssh/authorized_keys на сервере от имени нужного пользователя: каждая строка обычно начинается с ssh-ed25519, ecdsa-... или ssh-rsa и содержит один открытый ключ. Сравните отпечаток открытого ключа с отпечатком ключа клиента через ssh-keygen -lf ~/.ssh/authorized_keys (возможны несколько строк). Частный ключ никогда не копируют в authorized_keys и не отправляют на сайт. Если файл редактировался в Windows, убедитесь, что строки не разбиты и не содержат лишних символов; после сохранения повторите вход с клиента ssh -v пользователь@сервер, чтобы увидеть, какой ключ предлагается.
4. Проверьте sshd_config и блокировку учётной записиЕсли права исправлены, но сервер всё ещё отклоняет ключ, администратор с уже работающим альтернативным доступом должен проверить sshd -t (если вывод пустой, синтаксис принят), затем параметры PubkeyAuthentication, AuthorizedKeysFile, StrictModes и ограничения Match в действующей конфигурации SSH. Изменения выполняйте только после резервной копии и проверки серверного журнала. На сервере проверьте владельца домашнего каталога и файла ключей через ls -ld ~ ~/.ssh ~/.ssh/authorized_keys от имени целевого пользователя. Не выключайте StrictModes и не закрывайте последнюю действующую SSH-сессию до успешного входа с нового подключения.
5. Запустите sshd -dОтладочный sshd -d нельзя запускать вслепую на рабочем сервере вместо основной SSH-службы: он может занять порт или прервать доступ. Сначала проверьте конфигурацию sshd -t, затем журнал logread, journalctl или /var/log/messages — зависит от установленной службы журналирования. Для отдельного теста администратор может запустить экземпляр на свободном порту с параметрами -D -d -p НОМЕР после проверки правил сети, не останавливая текущий SSH. Никогда не тестируйте без резервного способа входа.

#Диагностика

На сервере выполните ls -ld ~ ~/.ssh ~/.ssh/authorized_keys и id. Включите подробный журнал: запустите отладочный экземпляр /usr/sbin/sshd -d -p 2222 и подключитесь ssh -p 2222 user@host; ищите Authentication refused. В Alpine журнал: /var/log/messages при включённом syslog. С клиента: ssh -vvv user@host показывает, какие ключи предлагаются.

#Исправление прав

Для нужной учётной записи проверьте ls -ld ~ ~/.ssh и ls -l ~/.ssh/authorized_keys, а также владельцев этих объектов. Домашний каталог не должен быть доступен на запись группе и остальным пользователям; .ssh обычно требует режим 700, authorized_keys — 600. Исправляйте владельца конкретного файла или каталога только после подтверждения пользователя: рекурсивный chown -R может затронуть несвязанные секреты и настройки. Сохраните альтернативный доступ к серверу до изменения SSH.

#Настройки sshd

В /etc/ssh/sshd_config уточните PubkeyAuthentication и AuthorizedKeysFile, проверьте результат командой sshd -t до перезапуска службы. Правила для входа root и состояние блокировки учётной записи требуют отдельного рассмотрения: не меняйте парольную запись командой usermod -p наугад и не включайте удалённый вход root только ради диагностики. При отказе входа по ключу читайте журнал sshd и вывод ssh -vvv, сохраняя существующий рабочий сеанс и возможность восстановления доступа.