APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Na autenticação por chave pública, o cliente demonstra acesso à chave privada e o servidor aplica a política da conta. A chave pública pode ser autorizada no lado do servidor; a chave privada permanece protegida no lado do cliente ou num mecanismo apropriado de gestão. O nome da conta remota faz parte do diagnóstico: a mesma chave pode estar autorizada para uma conta e não para outra. Uma mensagem Permission denied não demonstra, isoladamente, que o ficheiro da chave esteja corrompido. Importa saber que identidade foi oferecida e que métodos o servidor admite.
Aplicação guiada
Compara uma sessão autorizada de diagnóstico do cliente com os logs do servidor, no mesmo período e conta. Verifica o ficheiro de autorização efetivo, propriedade e permissões aplicáveis, sem tornar diretórios de chaves acessíveis a todos. Um agente com muitas identidades pode oferecer chaves que não interessam ao destino; selecionar a identidade pretendida e limitar as oferecidas ajuda a tornar o teste preciso. Não copies uma chave privada para um ticket, chat ou bastion para resolver uma rejeição. Confirma também regras de conta e políticas condicionais, porque a configuração pode variar por utilizador ou origem.
Uma chave está autorizada para deploy, mas o comando usa a conta pessoal do operador. Corrigir a seleção da conta resolve a divergência sem gerar outra chave.
Armadilhas comuns
Copiar chaves privadas para diagnóstico; abrir permissões indiscriminadamente; ignorar a conta efetiva.
Tópicos relacionados: Configuração efetiva e reprodução de falhas · Bastions, encaminhamento e exposição de portas
A identidade oferecida, a conta e a política do servidor devem coincidir.
Referência: sshd(8): server operation · OpenSSH concepts and OpenBSD-current manuals consulted 2026-09-29; distribution defaults vary