Summary
- O RFC 4251 descreve um registro local que associa nome de host e chave pública; depois do primeiro contato, a chave apresentada em novas conexões pode ser comparada à anotação.
- No OpenSSH, essa lembrança fica em
known_hosts. O cliente pode pedir confirmação de uma chave inédita e recusar uma chave alterada; um servidor já autenticado pode apresentar outras chaves antes de trocar a antiga.
Quando começa uma sessão SSH, o servidor apresenta uma chave de host. A matemática permite verificar a posse da chave privada correspondente. Falta ligar aquela chave ao servidor que o usuário queria alcançar. O RFC 4251, publicado em janeiro de 2006, expõe duas saídas: guardar localmente a associação entre nome e chave, ou confiar numa autoridade certificadora. A primeira dispensa um cartório central. Também deixa claro que a primeira anotação precisa de uma boa origem.
O RFC descreve o expediente que se tornou familiar: aceitar a chave na primeira visita, guardá-la e comparar as próximas. A máquina passa a ter memória. Quem intercepta o primeiro contato pode tentar gravar a própria chave como se fosse a correta; por isso o documento menciona verificar uma impressão digital por outro canal. Depois de registrada uma chave autêntica, um visitante com o mesmo nome e outra chave terá de explicar a diferença.
O caderno do OpenSSH chama-se ~/.ssh/known_hosts. O manual ssh(1) do OpenBSD explica o armazenamento das chaves conhecidas e o aviso ostensivo diante de uma mudança. Uma mudança não entrega, sozinha, o diagnóstico. O servidor pode ter sido reconstruído ou ter trocado de chave de forma legítima; também pode haver uma falsificação. O aviso transforma essa dúvida numa interrupção visível, em vez de deixar o próximo endereço igual apagar o encontro anterior.
O manual ssh_config(5) oferece diferentes graus de cerimônia. Com StrictHostKeyChecking=ask, o cliente consulta a pessoa antes de guardar uma chave nova e recusa uma mudança em host conhecido. accept-new registra desconhecidos automaticamente, mas barra a chave trocada. yes exige inserir as novas chaves de antemão. O primeiro aperto de mão pode ser mais rápido ou mais cuidadoso; a comparação com o passado continua sendo o centro da história.
Há também uma maneira elegante de mudar de chave. UpdateHostKeys permite que um servidor já autenticado anuncie chaves adicionais. A chave antiga ainda abre a conversa quando a nova é apresentada. O sucessor chega acompanhado por alguém que o cliente reconhece, antes que o antecessor se aposente.
ssh-keyscan recolhe chaves públicas num formato pronto para o caderno. O próprio manual avisa que a coleta não comprova a identidade do dono: um intermediário malicioso pode fornecer outra chave. Copiar a lista inteira em segundos não melhora o valor de uma apresentação errada. O desenho do SSH funciona porque transforma a primeira anotação numa pergunta permanente para as visitas seguintes.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance





