SELinux impedindo ssh via chave pública

SELinux impedindo ssh via chave pública

Eu tenho um usuário $USERque é 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, $USERagora 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 sealertestiver 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 scontexte tcontext, o scontextvalor indica o contexto necessário enquanto tcontextmostra o contexto do arquivo "authorized_keys" insatisfatório.

Neste caso, restorecon -R -v ~/.sshpor 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 sealertou audit2allow.

informação relacionada