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: DEBUG
gerou sshd
sequências diferentes de mensagens ao tentar chaves diferentes: a tentativa com falha incluiu uma mensagem que authorized_keys
não era legível, apesar de todas as chaves estarem no mesmo arquivo e na mesma sshd
instâ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 -LZ
produziu system_u:object_r:nfs_t:s0
um 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=3
a 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.