sshd
откажется принимать аутентификацию с открытым ключом, если домашний каталог пользователя доступен для группы, даже если ~/.ssh
имеет значение 700? Если разрешения для ~/.ssh
являются приемлемыми, почему разрешения для ~
имеют значение?
2 ответа
Хорошо, чтобы исправить это, вы можете либо пойти по небезопасному маршруту и установить StrictModes no
в вашем /etc/ssh/sshd_config
как уже упоминалось, либо вы можете пойти сложным путем и сохранить ssh-ключи для всех пользователей в каталоге, доступном только для root , Вот шаги для последнего:
Создайте каталог для хранения новых ключей. Здесь мы будем использовать
/usr/share/sshkeys
, который , возможно, не лучшее место, но лучшее, что я могу придумать из своей головы.sudo mkdir /usr/share/sshkeys
Отредактируйте
/etc/ssh/sshd_config
чтобы включить строкуAuthorizedKeysFile /usr/share/sshkeys/%u
Скопируйте старый файл авторизованного ключа от вашего пользователя (здесь он называется "exampleuser") в новый каталог
mv /home/exampleuser/.ssh/authorized_keys /usr/share/sshkeys/exampleuser
(Необязательно, но рекомендуется, поскольку exampleuser ожидает, что сможет добавлять ключи обычным способом). Свяжите новый файл ключа с расположением старого и предоставьте пользователю доступ к новому файлу ключа.
sudo chown exampleuser /usr/share/sshkeys/exampleuser sudo chmod 600 /usr/share/sshkeys/exampleuser ln -s /usr/share/sshkeys/exampleuser /home/exampleuser/.ssh/authorized_keys
Перезапустите демон ssh
sudo service sshd restart
Я предполагаю, что причина в том, что если ваш домашний каталог доступен для записи кем-то другим, то злонамеренный пользователь может создать ~/.ssh
, добавить нужные ключи и затем изменить разрешения для него до 700.
Даже если у вас уже есть ~/.ssh
, его можно просто переименовать во что-то другое и создать новый.
Однако в современных системах такой трюк обычно невозможен из-за работы с chown
только для суперпользователя, это не всегда имело место:
В более ранних версиях UNIX все пользователи могли запускать команду chown, чтобы изменить принадлежность принадлежащего им файла на принадлежность любого другого пользователя в системе. (http://www.diablotin.com/librairie/networking/puis/ch05_07.htm)
То, ведет ли себя chmod так или иначе, зависит от параметров компиляции libc, а в целях безопасности сервер OpenSSH немного параноидален.