SSH Authentication refused: bad ownership or modes for file

При попытке SSH подключения к серверу Linux, можно столкнуться с ошибкой «SSH Authentication refused: bad ownership or modes for file». Эта ошибка указывает на проблемы с правами доступа или владельцем файла .ssh/authorized_keys, который используется для аутентификации по публичному ключу.

Причины ошибки

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

Неправильный владелец: Владельцем файлов .ssh и authorized_keys должен быть пользователь, под которым вы пытаетесь подключиться.
Неправильная группа: Группа файлов .ssh и authorized_keys должна соответствовать группе владельца.
Слишком широкие разрешения: Файлы .ssh и authorized_keys не должны быть доступны для чтения или записи другим пользователям.

Решение проблемы

Проверка прав доступа и владельца: Используйте команды ls -l ~/.ssh и ls -l ~/.ssh/authorized_keys чтобы проверить текущие права доступа, владельца и группу.
Исправление владельца и группы: Используйте команды chown и chgrp для установки правильного владельца и группы. Например: chown $USER:$USER ~/.ssh ~/.ssh/authorized_keys.
Исправление разрешений: Используйте команду chmod для установки правильных разрешений. Каталог .ssh должен иметь права 700 (rwx——), а файл authorized_keys должен иметь права 600 (rw——-). Например: chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys.

Пример

Предположим, пользователь «john» пытается подключиться к серверу. После проверки, выясняется, что файл .ssh/authorized_keys имеет владельца «root» и права доступа 644.

Для исправления, необходимо выполнить следующие команды:

sudo chown john:john ~/.ssh ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Другие возможные проблемы

Если исправление прав доступа не помогло, проверьте следующие моменты:

SELinux/AppArmor: Эти системы безопасности могут блокировать доступ SSH к файлам. Проверьте логи и при необходимости настройте правила.
Конфигурация SSH сервера: Убедитесь, что в файле /etc/ssh/sshd_config не отключена аутентификация по публичному ключу (PubkeyAuthentication yes).
Проблемы с ключом: Убедитесь, что публичный ключ правильно скопирован в файл authorized_keys.
Firewall: Убедитесь, что firewall не блокирует SSH соединение (порт 22 по умолчанию).

Отладка

Для отладки можно запустить SSH сервер в режиме отладки: sshd -d. Это позволит увидеть более подробные сообщения об ошибках.

Альтернативные методы аутентификации

Если аутентификация по публичному ключу не работает, можно использовать другие методы, такие как password или keyboard-interactive. Однако, аутентификация по публичному ключу является более безопасной.

Расширенное Устранение Неполадок при Отказе в Аутентификации SSH

Если базовые шаги по исправлению прав доступа к файлу .ssh/authorized_keys не помогли устранить отказ в аутентификации SSH, необходимо копнуть глубже. Проблема может скрываться не только в неправильных правах доступа или режимах к файлу, но и в других аспектах конфигурации системы Linux.

Более Детальный Анализ

Проверка Ключей и Соединения: Убедитесь, что приватный ключ на стороне клиента соответствует публичному ключу, записанному в authorized_keys на сервере. Проверьте, что подключение происходит с правильного IP-адреса и порта. Иногда, если remote host identification has changed, необходимо удалить старую запись из ~/.ssh/known_hosts на клиенте.
Аутентификация по Паролю и Альтернативные Методы: Если аутентификация по публичному ключу (publickey) не работает, попробуйте временно разрешить аутентификацию по паролю (password) или keyboard-interactive в файле /etc/ssh/sshd_config (PasswordAuthentication yes). Это позволит проверить, работает ли вообще соединение с сервером. Другие методы аутентификации, такие как GSSAPI или PAM, также могут быть причиной проблемы, если они настроены неправильно.
Анализ Лог Файлов: Просмотрите логи SSH сервера (обычно в /var/log/auth.log или /var/log/secure) для получения более подробной информации об ошибке. Там может быть указана конкретная причина отказа в аутентификации, например, «permission denied» с указанием конкретного файла.
Сетевые Проблемы и Firewall: Проверьте, не блокирует ли firewall трафик SSH (порт 22 по умолчанию). Используйте tcpdump на сервере для анализа сетевого трафика и убедитесь, что пакеты от клиента доходят до сервера.
SELinux и AppArmor: Как уже упоминалось, SELinux и AppArmor могут ограничивать доступ SSH к файлам. Проверьте их статус и настройте правила, чтобы разрешить доступ к .ssh и authorized_keys. Например, для SELinux можно использовать команды `audit2allow` и `semanage` для создания и применения правил.
Владелец и Группа: Убедитесь, что правильный владелец и группа установлены для каталога .ssh и файла authorized_keys. Используйте команды chown и chgrp для исправления.
Разрешения: Убедитесь, что разрешения установлены правильно. Используйте команду chmod. Например: chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys. Неправильные режимы доступа могут привести к отказу в аутентификации.
Конфигурация SSH сервера: Проверьте файл /etc/ssh/sshd_config на наличие ошибок или ограничений, связанных с аутентификацией по ключу. Убедитесь, что опция `AuthorizedKeysFile` указывает на правильный путь к файлу authorized_keys. После внесения изменений в конфигурацию, перезапустите сервер SSH.

Отладка SSH

Для более глубокой отладки, можно запустить SSH сервер в режиме отладки (sshd -d) или использовать опцию -v (verbose) при подключении с клиента (ssh -v user@host). Это позволит увидеть более подробную информацию о процессе аутентификации и выявить причину ошибки.

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

<br />