Resumo

  • A RFC 9644 oferece modelos YANG comuns para capacidade e política ordenada de algoritmos SSH, mas não registra o resultado de cada negociação.
  • Um recibo defensável encadeia a revisão do registro, a capacidade da implementação, a configuração aprovada, as duas mensagens SSH_MSG_KEXINIT, as escolhas por direção, a chave de host, NEWKEYS, autenticação e resultado da aplicação.
  • O recibo proposto é uma prática operacional, não um formato imposto pela RFC; uma lacuna de observação deve aparecer como incerteza explícita.

O que sobreviveu ao incidente

O arquivo de configuração mostra que a equipe removeu um algoritmo antigo. O inventário confirma que a versão instalada suporta alternativas modernas. A trilha de aprovação identifica quem autorizou a mudança. Esses artefatos são úteis, mas não reconstroem a sessão que executou a operação crítica.

A RFC 9644 define os agrupamentos ietf-ssh-common, ietf-ssh-client e ietf-ssh-server, além do mecanismo que gera quatro módulos de enumerações a partir dos registros SSH mantidos pela IANA. Ela reduz ambiguidades na expressão da intenção. Não define uma telemetria universal de negociação nem garante que um cliente e um servidor chegarão ao resultado configurado.

Quatro fatos precisam continuar separados: o nome está registrado; a implementação declara suporte; a política permite o nome em certa posição; uma sessão o escolheu. O primeiro pertence ao vocabulário público, o segundo ao produto, o terceiro à governança local e o quarto ao protocolo em execução. Mesmo o quarto não demonstra sozinho quem era o host ou se a aplicação entregou o efeito esperado.

Registro não é recomendação

Os módulos gerados acompanham os registros de origem, recebem novas revisões e não tratam valores reservados ou ainda não atribuídos como escolhas disponíveis. A relação entre instantâneo de registro e revisão YANG permite saber qual vocabulário o controlador e o equipamento compartilhavam.

Mas a IANA registra identificadores com histórias e estados distintos. Uma entrada não constitui aprovação de risco para todos os ambientes. A RFC 9142 mostra que o nível de exigência ou recomendação dos métodos de troca de chaves evolui. Por isso, o recibo deve manter a fonte pública e a decisão local em campos diferentes: o que existia no registro e o que a organização permitia naquele momento.

Sem a revisão ou o hash do módulo, uma auditoria futura pode interpretar o passado com o vocabulário atual. Features e deviations que alterem a árvore exposta também precisam acompanhar essa primeira camada.

Capacidade é estoque, não consumo

Quando a feature opcional algorithm-discovery está ativa, supported-algorithms expõe dados operacionais config false. O recurso é valioso para uma migração: mostra que a implementação afirma possuir determinados métodos de troca de chaves, host key, cifra ou MAC.

Esse estoque de capacidade não prova consumo. Um algoritmo suportado pode estar proibido; um permitido pode não ser oferecido pelo par; um oferecido pode perder para uma preferência anterior. A captura também precisa de data, versão e identidade da implementação, porque upgrades podem alterar o conjunto.

Uma lista configurada ausente ou vazia exige atenção especial. Nessa condição, a RFC 9644 deixa o conjunto aceitável a cargo da implementação. Não existe um padrão universal que a interface possa preencher por conveniência. Se o comportamento efetivo não for conhecido, o recibo deve registrar essa indeterminação.

A política entra em contato com o outro lado

O transport-params-grouping mantém listas ordenadas para troca de chaves, host key, criptografia e MAC. A ordem exprime preferência decrescente. O registro de mudança deve preservar cada valor na posição original, a revisão da configuração, o aprovador e o alvo que a recebeu.

Na sessão, a RFC 4253 exige que as duas partes enviem listas em SSH_MSG_KEXINIT. A escolha de troca de chaves e host key segue a preferência do cliente entre opções também suportadas pelo servidor, respeitando os requisitos do método. Criptografia e MAC são escolhidos separadamente no sentido cliente-servidor e no sentido servidor-cliente.

Uma coluna única chamada “cifra” apaga essa diferença. A reconstrução precisa das duas ofertas e dos resultados direcionais. Quando não há interseção aceitável, a conexão é encerrada. A configuração aceita não prometia compatibilidade com qualquer par.

A chave existente não conta toda a história

O algoritmo de host key negociado identifica um procedimento, não a chave apresentada nem a decisão de confiança. A RFC 8332 torna a diferença concreta: o mesmo formato de chave pública RSA pode ser usado com rsa-sha2-256 ou rsa-sha2-512. A presença de uma chave RSA não determina qual algoritmo de assinatura ocorreu.

A RFC 9644 separa a identidade do cliente dos parâmetros de autenticação do servidor e permite referências a keystore e truststore. O desenho ajuda a manter distintas as perguntas certas: qual procedimento foi negociado, qual chave apareceu, por que ela foi aceita, como o cliente se autenticou e qual operação recebeu autorização.

Nenhum ponto de observação precisa enxergar tudo. Uma captura de rede pode registrar a negociação e não a decisão interna de confiança. Um log de cliente pode guardar a validação e não a oferta completa do servidor. O recibo correlaciona fontes, mas conserva como desconhecido o que não foi observado.

NEWKEYS não encerra o percurso

SSH_MSG_NEWKEYS ativa as chaves e os algoritmos recém-calculados. Duas ofertas compatíveis não provam que essa transição aconteceu. A transição, por sua vez, não prova a autenticação de usuário definida pela RFC 4252 nem a resposta útil da aplicação.

Um recibo operacional recuperável pode conter:

  • instantâneo do registro IANA e revisão ou hash dos módulos YANG gerados;
  • implementação, software, features e deviations;
  • observação datada das capacidades;
  • listas ordenadas exatas, revisão e aprovador da configuração;
  • capturas protegidas ou hashes dos dois KEXINIT;
  • escolhas de troca, host key, cifra e MAC com direção preservada;
  • fingerprint da chave de host, base de validação e resultado;
  • evidência de conclusão de NEWKEYS;
  • método e resultado da autenticação sem expor credenciais;
  • operação de aplicação, condição de aceite e resultado;
  • lacunas conhecidas e autoridade responsável pela conclusão.

As RFCs citadas não prescrevem esse documento unificado. Ele é uma solução de operação para as fronteiras entre o modelo de configuração, o protocolo e o serviço.

Recuperar uma afirmação, não só arquivos

O princípio de especificação inicial mínima de Heng Lu ajuda a definir o produto do controle. O objetivo não deve ser preservar todo dado possível, mas sustentar uma frase delimitada: em certa janela, uma operação identificada usou escolhas observadas compatíveis com a política aprovada, diante de um host validado, e produziu o resultado esperado.

A primazia do código em execução estabelece o critério quando há conflito. Registro e YANG organizam a camada simbólica. O tráfego e a aplicação determinam o que ocorreu. Se a intenção e a observação divergem, a sessão deve ser descrita pela observação, enquanto a divergência vira objeto de resposta.

Essa disciplina também melhora conclusões parciais. Só há configuração? É possível afirmar que a política foi aceita. Há negociação e NEWKEYS, mas não a validação? É possível afirmar a ativação dos algoritmos, não a identidade do host. Há transporte e identidade, mas falta o resultado da aplicação? A entrega do serviço continua sem prova.

Fontes

  1. Especificação inicial mínima
  2. Camadas de realidade e poder simbólico
  3. Primazia do código em execução
  4. Registro da RFC 9644 no Datatracker
  5. Página de informação da RFC 9644
  6. RFC 9644 em HTML
  7. RFC 9644 em texto
  8. RFC 9644 em XML
  9. Errata incorporada da RFC 9644
  10. Parâmetros SSH da IANA
  11. Parâmetros YANG da IANA
  12. RFC 4250: números atribuídos do SSH
  13. RFC 4252: autenticação SSH
  14. RFC 4253: transporte SSH
  15. RFC 6187: certificados X.509v3 no SSH
  16. RFC 8332: chaves RSA com assinaturas SHA-2
  17. RFC 9142: atualização dos métodos de troca SSH
  18. RFC 7950: YANG 1.1
  19. RFC 8341: controle de acesso à configuração
  20. RFC 8342: arquitetura de datastores de gestão