Resumo
- Uma correspondência SSHFP autenticada por DNSSEC vincula algoritmo e impressão de uma chave de host ao DNS owner selecionado. Ela não prova que esse nome era o serviço desejado nem codifica porta, usuário ou comando.
- A decisão combina seleção de nome, estado DNSSEC, comparação exata, prova SSH de posse e política local. A rotação ainda coordena caches DNS e known_hosts.
A prova certa para o nome errado
Nada foi falsificado. O resolvedor escolheu um nome completo, a cadeia DNSSEC autenticou o RRset e o servidor assinou a troca com a chave correspondente. Faltou provar por que db deveria virar aquele nome.
O RFC 4255 prevê o risco. Com nomes não qualificados, um caminho de busca injetado pode levar a outro host; por isso recomenda consultar primeiro uma base local. DNSSEC torna autêntica a resposta à pergunta feita, não a intenção que formulou a pergunta.
O registro operacional precisa separar argumento original, nome canônico, sufixo ou CNAME, owner SSHFP, endereço e porta.
O limite do registro
SSHFP é o tipo DNS 44. Seu RDATA contém algoritmo da chave, tipo de impressão e impressão. A verificação exige que o algoritmo da chave apresentada e o digest calculado sobre o blob público coincidam com um registro.
O transporte SSH ainda exige assinatura da troca, provando posse da chave privada naquela sessão. Posse não é exclusividade: uma cópia roubada produz a mesma prova.
O registro não contém porta, conta, comando, IP, papel ou validade. Uma associação para um hostname não decide qual daemon, bastion ou ambiente foi pretendido.
Secure é um estado específico
O RFC 4255 proíbe confiar por SSHFP quando o RR não foi autenticado por assinatura DNS confiável. Se o cliente delega a validação, precisa de canal protegido até o validador.
Secure, Insecure, Bogus e Indeterminate têm sentidos diferentes. Uma impressão igual sob Insecure pode informar, mas não ganha confiança automática. Bogus não deve ser rebaixado para preservar disponibilidade. Mesmo Secure autentica o RRset do nome consultado, não um sufixo DHCP ou regra de canonicalização.
Um “não” em SHA-256 não cai para SHA-1
IANA registra RSA, DSA, ECDSA, Ed25519, Ed448 e impressões SHA-1/SHA-256. Registro não prova suporte no runtime.
O RFC 6594 exige preferência por SHA-256 quando ambos existem. Se SHA-256 for testado e não combinar, a chave deve ser rejeitada em vez de procurar um SHA-1 coincidente. A telemetria deve guardar owner, algoritmo, tipo, digest calculado e cada resultado, não apenas sshfp=match.
A política local executa o veredito
O RFC 4255 permite ordenar SSHFP e bases locais. No OpenSSH atual, VerifyHostKeyDNS é no por padrão. Com yes, uma impressão Secure coincidente é implicitamente confiada; uma impressão insegura vira ask. Com ask, StrictHostKeyChecking ainda governa chaves novas.
known_hosts global e pessoal, Host/Match, canonicalização e CNAMEs permitidos mudam o ramo efetivo. É esse estado resolvido que deve ser preservado.
OpenSSH pode qualificar known_hosts como [hostname]:port, enquanto ssh-keygen -r publica por hostname. SSHFP não carrega porta. Um jump host também tem uma chave separada; autenticar o destino não autentica o salto.
Rotação em dois relógios
Trocar SSHFP pode distribuir uma chave; removê-lo pode participar da revogação quando a política o exige. Mas TTL, validade RRSIG e pins locais continuam vivos. Uma mudança autoritativa não é recusa imediata em todos os caches.
A rotação publica a nova impressão com matrícula segura, observa validadores materiais, sobrepõe chaves por período limitado, muda o serviço, remove a antiga e prova recusa após expiração.
Host não é usuário
SSH separa autenticação do servidor e autenticação do usuário. A chave aceita protege o canal ao servidor selecionado; não autoriza conta, shell, encaminhamento ou comando.
Testes devem variar nome curto, estados DNSSEC, falha SHA-256 com SHA-1 igual, conflito known_hosts, duas portas, bastion, chave copiada e recusa posterior de usuário/comando. Todo pass precisa nomear owner, estado, chave, porta, caminho, política e permissão seguinte.
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