APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma ligação SSH envolve decisões diferentes: conseguir chegar ao serviço, confirmar a identidade do servidor e autenticar a conta remota. Um timeout antes de receber resposta não é a mesma falha que uma chave de servidor alterada ou uma rejeição de autenticação. O ficheiro known_hosts regista identidades de servidores conhecidas; não concede ao utilizador acesso à conta remota. Quando aparece um aviso de alteração de chave, o cliente encontrou uma identidade diferente da guardada. Uma reconstrução autorizada pode explicar a diferença, mas essa explicação precisa de confirmação por um canal de confiança independente da ligação suspeita.
Aplicação guiada
Num exercício de suporte, regista origem, nome resolvido, porta, hora e fase da falha. Usa diagnóstico detalhado apenas onde estás autorizado, retirando informação sensível antes de partilhar logs. Compara a fingerprint apresentada com um registo de gestão ou um responsável contactado por canal conhecido. Depois de confirmar a mudança, atualiza apenas a entrada pertinente. Apagar todo o known_hosts perde o histórico dos restantes servidores e não valida a nova identidade. Os exemplos deste percurso usam nomes fictícios e comandos de consulta; qualquer alteração real exige o processo de acesso e mudança da organização.
Depois de reconstruir batch.example.test, uma consola de gestão confirma a nova fingerprint. Só então a equipa atualiza o registo correspondente.
Armadilhas comuns
Confundir chave do servidor com chave do utilizador; aceitar qualquer fingerprint para recuperar rapidamente acesso.
Tópicos relacionados: Autenticação por chave e conta remota · Configuração efetiva e reprodução de falhas
Localiza a fase da falha antes de alterar credenciais ou confiança.
Referência: ssh(1): OpenSSH client · OpenSSH concepts and OpenBSD-current manuals consulted 2026-09-29; distribution defaults vary