
Eu tenho um usuário $USER
que é uma conta de usuário do sistema com um arquivo de usuários autorizados. Quando tenho o SELinux habilitado, não consigo fazer ssh no servidor usando a chave pública. Se eu setenabled 0
, $USER
agora posso fazer login.
Qual bool/política do SELinux devo alterar para corrigir esse comportamento sem desabilitar totalmente o SELinux?
É importante notar que $USER
é possível fazer login com uma senha nesta configuração padrão do SELinux. Eu apreciaria algumas dicas sobre o que está acontecendo aqui e por que o SELinux não está bloqueando isso. (Desabilitarei completamente a autenticação por senha depois que isso for resolvido, então é mais agradável saber esta questão)
Responder1
Supondo que as permissões do sistema de arquivos estejam corretas em ~/.ssh/*, verifique a saída de
sealert -a /var/log/audit/audit.log
Deve haver uma pista em uma entrada AVC ali. Muito provavelmente a solução se resumirá a executar:
restorecon -R -v ~/.ssh
Responder2
Se sealert
estiver faltando em um sistema, como estava em um sistema que encontrei recentemente, também existe a possibilidade de 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.
Dividindo o 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.
Embora audit2allow não tenha informado concisamente como corrigir o problema, observando scontext
e tcontext
, o scontext
valor indica o contexto necessário enquanto tcontext
mostra o contexto do arquivo "authorized_keys" insatisfatório.
Neste caso, restorecon -R -v ~/.ssh
por si só não funcionou, mas aplicar o contexto desejado funcionou:
$ sudo semanage fcontext --add -t ssh_home_t "/path/to/my/.ssh(/.*)?"; \
$ sudo restorecon -FRv /path/to/my/.ssh
Conforme necessário, altere os nomes e/ou contexto dos recursos com base no que é visto no AVC. Detalhes precisos nesta resposta foram construídos para resolver um problema relacionado a "keys_autorizadas", mas uma solução poderia seguir esse modelo mesmo se um arquivo ou contexto diferente fosse indicado no AVC produzido por sealert
ou audit2allow
.