Вопросы Теги

Используйте ключевую аутентификацию SSH с пользовательским пользовательским $HOME

Проект Скрежета с открытым исходным кодом указывает, что OpenBSD обеспечивает пакеты. Используйте их. Это не идеальная замена AdobeFlash, но это - открытый исходный код и так может быть скомпилировано в системах, для которых не предварительно компилирует Adobe.

4
09.09.2018, 18:02
3 ответа

Не имеет значения, кто владеет/pkg/. Если это принадлежало бы usera затем у Вас были бы проблемы с userb и т.д. Таким образом, это должно быть что-то еще, что препятствует тому, чтобы SSHD использовал authorized_keys файл. Необходимо проверить, перезаписываем ли этот файл только владельцем и если он принадлежит надлежащему пользователю. То же применяет все родительские каталоги.

2
27.01.2020, 20:58
  • 1
    Спасибо, Вы правы. Полномочия файла были корректны, оба 700. Проблема была вызвана SELinux. Я узнал, что должен был выполнить команду 'restorecon-R-v ~/.ssh' bugzilla.redhat.com/show_bug.cgi?id=476362 –  marquies 14.09.2012, 10:22
  • 2
    , я рад Вы, где способный для обнаружения этого. Это - хорошая идея упомянуть рассматриваемый, что Вы используете SELinux, если у Вас есть какие-либо проблемы с полномочиями, доступ и т.д. –  Krzysztof Adamski 14.09.2012, 10:27

Это все или ничего: если Вы поворачиваетесь StrictModes опция прочь, sshd никогда не будет проверять режимов файла. Нет никакого способа сказать, что определенные нечетные случаи в порядке, такие как перезаписываемый группой каталог (который в порядке, если пользователь является одним в группе).

OpenSSH проверяет полномочия и владение ~/.ssh/authorized_keys и его содержание каталогов, рекурсивно вызывающих вверх. Однако это останавливает сравнение, когда это достигает корневого каталога. Например, в классическом расположении, где файл авторизации /home/joe/.ssh/authorized_keys и /home/joe корневой каталог пользователя, только /home/joe/.ssh/authorized_keys, /home/joe/.ssh и /home/joe проверяются.

Таким образом, в то время как Ваш сценарий очень сомнителен (/pkg должен принадлежать корню, с дополнительными полномочиями группы при необходимости), он не должен влиять на ssh.

Если какие-либо символьные ссылки включены, обратите внимание, что ssh разворачивает все символьные ссылки прежде, чем запустить его проверки.

Системные журналы могли бы иметь релевантную информацию. Проверьте, вызывают ли Ваши неудавшиеся попытки входа в систему какое-либо сообщение журнала.

Проверьте, что Ваша версия ssh выполняет те же проверки как моя (я посмотрел на источник OpenSSH 5.5p1) путем выполнения демона режима отладки на пользовательском порте (sshd -d -p 2222). Использовать strace -f -efile sshd -d -p 2222 при необходимости проверять который разрешение файлов проверки сервера. Если эти проверки разрешения не являются проблемой, добавляя больше -d флаги могли бы пролить некоторый свет.

Если у Вас есть AppArmor, существует также возможность, что он ограничивает ssh сервер чтением файлов в пользователях .ssh каталоги. Если у Вас будут AppArmor и корневые каталоги в нестандартном месте, то необходимо будет обновить политики AppArmor (не только для SSH). Посмотрите Проявляют сбои для запуска, потому что это не может считать.Xauthority.

1
27.01.2020, 20:58

Я столкнулся с той же проблемой, используя '/data' в качестве базового dir для пользовательских каталогов. Для меня было недостаточно запустить 'restorecon -R -v ~/.ssh'. Сначала я должен был запустить

# semanage fcontext -a -e /home /data

от имени root, а затем (также от имени root, поскольку каталог /data содержал каталог, принадлежащий root)

# restorecon -R -v /data
0
27.01.2020, 20:58

Теги

Похожие вопросы