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.