12
ключи надлежащим образом размещены в ~/.ssh/authorized_keysRedHat 6/Oracle Linux 6 не позволяет ключ аутентификации через SSH
Однако SSH продолжает запрашивая пароль.
A
ответ
28
несколько вопросов, в основном привилегии - но и связанные с SELinux на RedHat 6
Следующий скрипт должен исправить их все, пожалуйста, замените <user>:<group> с согласующим ID_пользователем и группами
chown -R <user>:<group> ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
restorecon -R -v ~/.ssh
+3
, вы не должны изменять разрешения для файлов, чтобы они были доступны для чтения, даже если они находятся в защищенном каталоге 'restorecon -R -v $ HOME/.ssh' - вот что сделал трюк для меня – feniix
+0
Да, он должен быть только владельцем. В моей коробке rhel6 все еще работает с 600 – feniix
+0
Вы имеете в виду мое предложение было плохо? потому что я вижу, что вы отредактировали свой ответ с 600 для файлов. – feniix
1
выше ответ довольно хорошо, у меня есть дополнение & предложение. Добавление приведено в строке 2 ниже, поскольку разрешения для домашнего каталога не являются более разрешительными, чем rwxr-x --- для аутентификации ключа ssh.
cd ~
chmod g-w,o-rwx .
chmod 700 .ssh
cd .ssh
chmod 600 *
chmod 644 authorized_keys
chmod 644 known_hosts
chmod 644 config
restorecon -R -v ../.ssh
Предложение заключается в использовании опции -vv при тестировании.
5
Я согласен с приведенными выше изменениями, работающими над большинством вариантов linux в корневой учетной записи. У меня была проблема с RedHat 6.3 с попыткой получить учетную запись postgres для использования DSA auth. (6.3 работает в VirtualBox)
Проблема может быть в том, что основные разрешения selinux неверны. Restorecon не поможет в этом случае.
(After restorecon)
drwx------. postgres postgres unconfined_u:object_r:var_lib_t:s0 .ssh
Я установил это с:
chcon -R -t ssh_home_t .ssh
Это решить этот экземпляр проблемы.
+0
Я искал три дня для ответа! Только когда я запустил stat в файле авторизованных ключей, я заметил контекст SELinux в файле. Я сравнил его с авторизованным файлом ключей для другого пользователя и заметил разницу! Спасибо, Грег! – BamaPookie
+0
Еще один момент, который я обнаружил: если впоследствии вы запустите restorecon в этом .ssh каталоге, вы потеряете изменения, внесенные командой chcon. Вам также нужно добавить политику, которая будет правильно использовать контекст в случае ссылки на файловую систему. Я сделал это со следующей командой: semanage fcontext -a -t ssh_home_t "/path/to/service/home/.ssh(/.*)?". (Обязательно используйте полный путь.) – BamaPookie
+1
Исправленная команда: semanage fcontext -a -t ssh_home_t "/path/to/service/home/\.ssh(/.*)?" – BamaPookie
1
У меня была и эта же проблема, предлагаемое решение выше не разрешило мне дело. Резюмируя инструкция abowe вместе:
- Проверьте следующий логфайл на целевой системе возможных деталей ошибок:/вар/Журнал/безопасный
- Разрешения файлов пользователей ~/.ssh каталог должен быть 600 и файлы должны быть принадлежит «user: group»
- Разрешение каталога ~/.ssh должно быть 700 и принадлежит «Пользователь: группа»
- Разрешение домашнего каталога пользователя, т.е. «~» (= «~/.ssh/..») должно быть 755. Если разрешения - это f.ex 775, в моей системе сбой авторизации ssh.
уш Брюно
+0
Разве эта инструкция решила дело для вас? Или это просто компиляция? –
Проверка/вар/Журнал/безопасный он будет иметь информацию, если открытый ключ не удалось для авт. Скорее всего, файлы (файлы) имеют неправильное разрешение на чтение/запись в ~/.ssh. – mguymon
В моем случае перм были в порядке. это было связано с SELinux, см. ниже –