Por que o selinux está bloqueando o acesso remoto ssh sem uma senha?

Question

Eu tenho um servidor do CentOS 7. Eu configurei /root/.ssh/authorized_keys no host que estou tentando fazer login sem uma senha. (Sim, permitir acesso root remoto é uma má idéia, mas este é um servidor interno.) Ssh falha e existe isso no log de auditoria do 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'

Aqui estão as permissões e o contexto do material .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

Eu comparei as permissões e os contextos com os de outro sistema que permite o login ssh sem uma senha e são os mesmos.

Na mensagem de auditoria, não há indicação de qual arquivo o selinux está preocupado, apenas "res = fail".

No sistema que funciona, a entrada de log tem isso:

subj=system_u:system_r:sshd_t:s0-s0:c0.c1023

Estou confuso. Não há arquivo em /root/.ssh que tenha contexto system_u: system_r: sshd_t. Então, não entendo porque esse contexto está registrado.

Existe uma maneira de saber qual deve ser o contexto de todos os arquivos relacionados ao .ssh? Sim, eu toquei com restorecon sem sorte.

    

Answer 1

Você é rápido em pular no SELinux .... tem certeza de que o / etc / ssh / sshd_config está configurado corretamente para permitir acesso root via ssh? Você reiniciou o serviço sshd se tiver feito alguma alteração nos arquivos de configuração.

Você tentou configurar o SELinux como permissivo e testando isso?

Você sabe, se o SELinux estava negando o acesso, eu esperaria ver algum tipo de erro do AVC (Access Vector Cache) no /var/log/audit/audit.log. Lembre-se de que o audit.log é usado para mais do que apenas os problemas do SELinux. Assim, tudo o que você está recebendo é simplesmente um relatório de login com falha, NÃO um erro do SELinux.

Você tem certeza absoluta de que o par de chaves openssh público / privado você realmente trabalha em um contexto ssh. Você pode tentar o log usando o comando ssh com as opções -v para depurar isso e ver.

Eu também verificaria as mensagens / var / log / messages e / var / log / secure para mais informações.

    

Answer 2

Existe um breve artigo sobre esta questão. Diz que

may be because the SELinux contexts have not been correctly set on the .ssh folder and authorized keys file [...] The way to fix this is to run

# restorecon -R -v /root/.ssh

O artigo também mostra como definir permissões corretamente desde o começo:

# chmod 755 /root/.ssh/
# chmod 600 /root/.ssh/authorized_keys
# restorecon -R -v /root/.ssh

Apesar de eu discordar do artigo sobre o primeiro comando, já que no meu VPS eu tenho

# chmod 700 /root/.ssh/

Da minha experiência pessoal, aprendi várias coisas importantes sobre a autenticação da chave ssh.

1. Se você tiver novas versões do OpenSSH (meus problemas começaram com o OpenSSH 7.0), as chaves DSA não funcionarão, porque "O suporte para as chaves do host e do usuário ssh-dss está desativado por padrão em tempo de execução". A solução é usar chaves RSA ou adicionar PubkeyAcceptedKeyTypes=+ssh-dss a /etc/ssh/sshd_config na máquina remota e ~/.ssh/config na máquina cliente.
2. A depuração dos problemas no lado do cliente pode ser feita adicionando a opção -vvvvv to ssh chama ssh -vvvvvv [email protected]
3. A depuração dos problemas no lado do servidor pode ser feita editando /etc/ssh/sshd_config

SyslogFacility AUTH

LogLevel DEBUG

(ajuda sobre opções pode ser obtida por # man sshd_config )

Então, durante a conexão ssh, veja /var/log/debug . Se você não consegue encontrar depuração log, olhe para /var/log/messages e /var/log/secure (como último recurso, veja quais configurações você tem em /etc/syslog.conf ).