Почему selinux блокирует удаленный доступ по ssh без пароля?
У меня есть сервер 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
I ' Мы сравнили разрешения и контексты с разрешениями и контекстами другой системы, которая разрешает вход по 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 .... вы уверены, что / etc / ssh / sshd_config правильно настроен для разрешения root-доступа через 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 для получения дополнительной информации.
По этому поводу есть небольшая статья . В нем говорится, что
может быть из-за того, что контексты 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-ключа.
- Если у вас есть в новых версиях OpenSSH (мои проблемы начались с OpenSSH 7.0), то ключи DSA не будут работать, потому что «Поддержка хоста ssh-dss и ключей пользователя отключена по умолчанию во время выполнения». Решение - либо использовать ключи RSA, либо добавить
PubkeyAcceptedKeyTypes = + ssh-dssв/ etc / ssh / sshd_configна удаленном компьютере и в~ / .ssh / configна клиентском компьютере. - Отладка проблем на стороне клиента может быть выполнена путем добавления опции
-vvvvvдля вызова sshssh -vvvvvv (скрыто) проблемы на стороне сервера могут быть решены путем редактирования/ etc / ssh / sshd_config
SyslogFacility AUTH
LogLevel DEBUG
(справку по параметрам можно получить по # man sshd_config )
Затем во время соединения ssh посмотрите / var / log / debug . Если вы не можете найти отладку
log, посмотрите / var / log / messages и / var / log / secure (в крайнем случае посмотрите, какие настройки у вас есть в /etc/syslog.conf ).
У меня была эта проблема на CentOS 7. Я обычный пользователь Linux на базе Debian, так что я был рыбой из воды. Я заметил, что на некоторых серверах это работало, а на одном - нет. В audit.log не было ничего полезного, и в secure.log тоже ничего не было сказано.
Я обнаружил, что единственной реальной разницей были некоторые различия в контексте безопасности файлов и каталогов между теми, которые работали, и теми, которые не работали.Обеспечьте безопасность с помощью
sudo ls -laZ
Вы должны увидеть 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 /
В случаях, когда 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.