У меня есть сервер CentOS 7. Я установил /root/.ssh/authorized_keys на хосте, на который я пытаюсь войти без пароля. (Да, разрешение удаленного корневого доступа - плохая идея, но это внутренний сервер.) Ssh не работает, и это есть в журнале аудита selinux.
type=USER_LOGIN msg=audit(1494544798.597:481313): pid=18660 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=? addr=xx.xx.xx.xx terminal=ssh res=failed'
Вот разрешения и контекст файлов .ssh:
# ls -aZ /root/.ssh
drwx------. root root system_u:object_r:ssh_home_t:s0 .
dr-xr-x---. root root system_u:object_r:admin_home_t:s0 ..
-rw-------. root root system_u:object_r:ssh_home_t:s0 authorized_keys
-rw-r--r--. root root unconfined_u:object_r:ssh_home_t:s0 known_hosts
Я сравнил разрешения и контексты с разрешениями и контекстами другой системы, которая позволяет входить в систему по ssh без пароля, и они такие же.
В контрольном сообщении нет указания на то, о чем заботится selinux файла, просто "res = fail".
В системе, которая работает, в журнале есть такая запись:
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
Итак, я запутался. В /root/.ssh нет файла с контекстом system_u: system_r: sshd_t. Итак, я не понимаю, почему этот контекст регистрируется.
Есть ли способ узнать, каким должен быть контекст всех файлов, связанных с .ssh? Да, безуспешно играл с restorecon.
Есть короткий статья по этому вопросу. Он говорит, что
может быть потому, что контексты SELinux были неправильно установлены в папке .ssh и файле авторизованных ключей [...] Способ исправить это - запустить
# restorecon -R -v /root/.ssh
В статье также показано, как правильно установить разрешения с самого начала:
# chmod 755 /root/.ssh/
# chmod 600 /root/.ssh/authorized_keys
# restorecon -R -v /root/.ssh
Хотя я не согласен со статьей о первой команде, так как на моем VPS у меня
# chmod 700 /root/.ssh/
Из своего личного опыта я узнал несколько важных вещей об аутентификации ssh-ключа.
PubkeyAcceptedKeyTypes=+ssh-dss к /etc/ssh/sshd_config на удаленной машине и на ~/.ssh/config на клиентской машине.-vvvvv позвонить по ssh ssh -vvvvvv user@example.com/etc/ssh/sshd_configSyslogFacility AUTH
LogLevel DEBUG
(помощь по опциям можно получить у # man sshd_config)
Затем во время ssh-соединения посмотрите /var/log/debug. Если вы не можете найти журнал отладки, посмотрите /var/log/messages и /var/log/secure (в крайнем случае посмотрите, какие настройки у вас /etc/syslog.conf).
Вы быстро переходите на SELinux .... вы уверены, что / etc / ssh / sshd_config правильно настроен для разрешения корневого доступа через ssh? Вы перезапустили службу sshd, если вы внесли какие-либо изменения в файлы конфигурации.
Вы пробовали установить SELinux в разрешающий режим и протестировать это.
Вы знаете, если бы SELinux отказывал в доступе, я бы ожидал увидеть какую-то ошибку AVC (Access Vector Cache) в /var/log/audit/audit.log. Помните, что audit.log используется не только для решения проблем с SELinux. Таким образом, вы получаете просто отчет о неудачном входе в систему, а НЕ ошибку SELinux.
Вы абсолютно уверены, что имеющаяся у вас пара открытых / закрытых ключей openssh действительно работает в контексте ssh? Вы можете попробовать войти в журнал с помощью команды ssh с опциями -v, чтобы отладить это и посмотреть.
Я бы также проверил файлы / var / log / messages и / var / log / secure для получения дополнительной информации.
В случаях, когда restorecon -R -v ~/.ssh не работает, и виноват SELinux по sealert или audit2allow отчеты, и когда контексты SELinux для .ssh При изменении папки, следующее может исправить проблемы входа в систему с аутентификацией на основе ключа:
$ sudo semanage fcontext --add -t ssh_home_t "/path/to/my/.ssh(/.*)?"; \
$ sudo restorecon -FRv /path/to/my/.ssh
Это исправление было эффективным, когда наблюдались AVC, показанные ниже:
$ sudo audit2allow -w -a
type=AVC msg=audit(1548909218.552:1037): avc: denied { read } for pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
В моем случае изучал
корень #> journalctl -f
затем сообщите SELinux, что разрешено использование домашних каталогов nfs:
корень #> setsebool -P use_nfs_home_dirs 1
Это решит мою проблему.
У меня была эта проблема на CentOS 7. Я обычный пользователь Linux на базе Debian, так что я был рыбой из воды. Я заметил, что на некоторых серверах это работало, а на одном - нет. В audit.log не сказал ничего полезного и secure.log тоже ничего не дал. Я обнаружил, что единственной реальной разницей были некоторые различия в контексте безопасности файлов и каталогов между теми, которые работали, и теми, которые не работали. Получите безопасность с
sudo ls -laZ <user-home>/.ssh
каталога (я предполагаю, что в sshd_config много значений по умолчанию).
Вы должны увидеть некоторые ssh_home_t и user_home_t атрибуты. Если вы этого не сделаете, используйте chcon команда для добавления недостающих атрибутов.
Например:
home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home/.ssh"
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"
В моем случае подозреваю, что пользователь был создан нестандартным способом. Его дом был каталогом в /var/lib.
Больше информации в: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/