Início / server / Perguntas / 1179705
Accepted
ljcorsa
Asked: 2025-04-24 05:50:29 +0800 CST

Par de chaves SSH SOMENTE aceito pelo sshd no modo de depuração

  • 772

Usando o Rocky 9.4 e o OpenSSH 8.7p1, tenho um par de chaves RSA que não é aceito, a menos que o sshd esteja em modo de depuração. (Felizmente, tenho um par antigo que funciona).

Desativei o SSH_AUTH_SOCK e verifiquei que nenhum agente está envolvido. Movi o ~/.ssh/config para evitar essa complicação. Verifiquei que o ~/.ssh/ está no modo 0700, id_rsa e authorized_keys estão em 0400 e known_hosts está em 0600. Confirmei que a chave pública correta está em authorized_keys e verifiquei usando 'ssh-keygen -l'.

Quando o sshd está sendo executado como um serviço e eu executo 'ssh -avv -i ~/.ssh/id_rsa localhost', vejo:

Offering public key:  (with the correct filename and SHA256 fingerprint)
we sent a publickey packet, wait for reply
Authentications that can continue:  publickey, ...
we did not send a packet, disable method
Next authentication method: keyboard-interactive

... e sou solicitada minha senha normal.

/var/log/secure mostra:

Connection from 127.0.0.1 ...
Failed publickey for (user) and shows the same correct SHA256 code.

Encontrei o conselho de que eu deveria interromper o serviço sshd e executá-lo manualmente em modo de depuração. Abri uma segunda sessão como root e executei:

systemctl stop sshd
/usr/sbin/sshd -D -ddd -e

Quando repito o comando 'ssh -avv -i ~/.ssh/id_rsa localhost' na janela do usuário original, vejo:

Offering public key:  (with the correct filename and SHA256 fingerprint)
we sent a publickey packet, wait for reply
Server accepts key:   (with the correct filename and SHA256 fingerprint)
Enter passphrase for key '(filename)':  (I type passphrase)
Authenticated to 127.0.0.1 (via proxy) using "publickey".

... e consegui fazer login usando a mesma chave.

Eu esperava que sshd -D -ddd me ajudasse a descobrir o problema, mas ele aceita minha chave com prazer.

Atualização 2024-04-30

Seguindo a sugestão de @mircea-vutcovici , a configuração LogLevel: DEBUGgerou sshdsequências diferentes de mensagens ao tentar chaves diferentes: a tentativa com falha incluiu uma mensagem que authorized_keysnão era legível, apesar de todas as chaves estarem no mesmo arquivo e na mesma sshdinstância!

Meu diretório home é um compartilhamento NFS e o SELinux está sendo aplicado, então pesquisei mais usando a sugestão do @grawity : ls -LZproduziu system_u:object_r:nfs_t:s0um rótulo genérico do SELinux. Aparentemente, isso é um problema se a montagem NFS preceder o patchwork de carregamento da política SELinux: selinux: faça o NFS rotulado funcionar quando montado antes do carregamento da política . Esse problema foi corrigido em 2023 e deveria ter sido incluído no Rocky 9.4 (meados de 2024). Dito isso, /homeé montado com NFS, vers=3a propósito.

Finalmente, encontrei um encantamento útil serverfault: Rótulos SELinux errados em casas NFS? : setsebool -P use_nfs_home_dirs on. Agora posso usar ambas as chaves, mas ainda não consigo entender por que elas foram tratadas de forma diferente, já que ambas as chaves públicas estão no mesmo arquivo e ambas as chaves privadas têm as mesmas permissões na mesma pasta.

Acabei de me deparar com uma pergunta semelhante de 13 anos atrás: a autenticação de chave pública falha SOMENTE quando sshd é daemon . Aparentemente, o SELinux é sempre o problema :-) Vou dar os créditos ao @grawity por uma resposta que me fez cair em uma grande enrascada.

ssh

2 respostas

  1. Best Answer

    Meu palpite é que você habilitou o SELinux e o authorized_keysarquivo tem o rótulo errado, então ele pode ser lido por 'sshd' iniciado em sua sessão de usuário interativa, mas não pode ser lido por 'sshd' iniciado em 'init', pois eles são executados em contextos SELinux diferentes.

    Ou seja, iniciar o sshd manualmente -dafeta outras coisas além do "modo de depuração". (Para minimizar as diferenças, o modo de depuração deve ser habilitado através do sshd_config, como na publicação de Mircea Vutcovici.)

    Inspecione o arquivo com ls -lZ, depois execute restorecon -v-o (o que eu acho que é a maneira correta de consertar isso?), depois ls -lZexecute-o novamente.

    • 12

  2. Certifique-se de ter sua chave pública no ~/.ssh/authorized_keysarquivo do usuário remoto. Cada linha deve conter uma única chave.

    Edite /etc/ssh/sshd_configo arquivo e altere a linha:

    #LogLevel INFO

    para algo como:

    LogLevel DEBUG

    Os valores possíveis são: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, e DEBUG3.

    Em seguida, reinicie o sshdserviço:

    systemctl status sshd.service
systemctl restart sshd.service
systemctl status sshd.service

    Se precisar de mais detalhes, você pode usar o strace sshdenquanto estiver executando como daemon:

    sudo strace -s300 -fyyTttp $(pgrep -f 'sshd -D') -o strace-sshd-$HOSTNAME-$(date +%F_%H%M%S).txt`

    Isso gerará um arquivo de rastreamento na pasta local. Verifique o que está acontecendo no arquivo de rastreamento.

    • 10

relate perguntas