☰

SELinux предотвращает ssh через открытый ключ

tag-icon • tag-icon ssh centos selinux
SELinux предотвращает ssh через открытый ключ

У меня есть пользователь $USER, который является системной учетной записью пользователя с файлом авторизованных пользователей. Когда у меня включен SELinux, я не могу подключиться к серверу по ssh с помощью открытого ключа. Если я setenabled 0, $USERтеперь могу войти.

Какую политику/буль SELinux следует изменить, чтобы исправить это поведение, не отключая SELinux полностью?

Стоит отметить, что $USERв этой конфигурации SELinux по умолчанию можно войти в систему с паролем. Я был бы признателен за понимание того, что здесь происходит и почему SELinux не блокирует это. (Я полностью отключу аутентификацию по паролю после того, как эта проблема будет решена, поэтому этот вопрос будет более приятным для понимания)

решение1

Предполагая, что разрешения файловой системы на ~/.ssh/* верны, проверьте вывод

sealert -a /var/log/audit/audit.log

Там должна быть подсказка в записи AVC. Скорее всего, решение будет сведено к запуску:

restorecon -R -v ~/.ssh

решение2

Если sealertв системе отсутствует, как это было в системе, с которой я недавно столкнулся, также существует вероятность audit2allow:

$ 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.

Разбираем AVC:

avc: denied { read } for pid=13996 comm="sshd" name="authorized_keys" dev="dm-0" ino=4663556
    "sshd" was denied read on a file resource named "authorized_keys".
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023
    SELinux context of the sshd process that attempted the denied action.
tcontext=system_u:object_r:admin_home_t:s0 tclass=file
    SELinux context of the authorized_keys file.

Хотя audit2allow не дал четкого указания, как исправить проблему, при просмотре scontextи tcontextзначение scontextуказывает на необходимый контекст, а tcontextпоказывает неудовлетворительный контекст файла «authorized_keys».

В данном случае restorecon -R -v ~/.sshсамо по себе не сработало, но применение нужного контекста сработало:

$ sudo semanage fcontext --add -t ssh_home_t "/path/to/my/.ssh(/.*)?"; \
$ sudo restorecon -FRv /path/to/my/.ssh

При необходимости измените имена ресурсов и/или контекст на основе того, что видно в AVC. Точные детали в этом ответе были составлены для решения проблемы, связанной с "authorized_keys", но решение может следовать этой модели, даже если в AVC, созданном или , указан другой файл или sealertконтекст audit2allow.

Связанный контент