Resumo

  • A primeira troca de chaves produz o segredo K e o hash H; esse primeiro H, derivado da negociação efetiva, torna-se o identificador da conexão.
  • Um rekey pode mudar métodos, chaves de tráfego, vetores, contextos e até a host key. O identificador original permanece, separando renovação da proteção de renascimento da sessão.
  • A autenticação por chave pública assina o identificador junto com usuário, serviço, método, algoritmo e chave. Isso impede replay entre conexões, mas não concede automaticamente shell, encaminhamento ou qualquer outra operação.

Estado duradouro e proteção renovável

Um terminal remoto pode continuar por horas. Transferências e túneis acumulam estado que o usuário não quer perder. As chaves que cifram os pacotes, porém, não precisam durar tanto quanto a atividade.

Se cada renovação destruísse a sessão, todos os protocolos acima do transporte teriam de recomeçar. Se cada chave nova ganhasse uma identidade separada, a autenticação realizada antes da troca perderia seu ponto de ligação com o tráfego posterior.

A RFC 4251 dividiu o SSH 2 em transporte, autenticação de usuário e conexão. A primeira camada autentica o servidor e protege o fluxo. A segunda autentica o usuário do lado cliente. A terceira multiplica shells, subsistemas e encaminhamentos. O desenho permite que a camada protetora se renove sem reescrever, por conta própria, a conversa mantida acima dela.

Nenhum par escolhia sozinho o nome da conexão

Cliente e servidor enviam SSH_MSG_KEXINIT. O pacote leva um cookie aleatório e listas ordenadas para troca de chaves, host key, cifra, integridade e compressão. A escolha parte da preferência do cliente e encontra o primeiro método que o servidor também aceita segundo as regras aplicáveis.

O método selecionado calcula um segredo compartilhado K e um hash da troca H. Na construção Diffie–Hellman original do SSH 2, entram em H as identificações dos protocolos, os dois KEXINIT brutos, a chave pública do servidor, os valores efêmeros e o segredo compartilhado.

Mudar a versão, a oferta de algoritmos, a host key ou um valor efêmero muda a transcrição. O hash não é um número atribuído por um cadastro nem um rótulo declarado por um dos lados. Os dois participantes deixam material verificável em sua formação.

Os cookies reduzem a capacidade de prever o resultado. Ainda assim, o identificador de sessão não é segredo: divulgá-lo não revela K nem permite produzir proteção válida. Seu valor vem do contexto, não de funcionar como credencial portadora.

O servidor assina o hash com a host key negociada. A verificação demonstra que o detentor daquela chave privada assinou a troca. Não demonstra, sem outra evidência, que a chave pertence ao nome de host pretendido. O cliente ainda precisa de uma associação salva, certificado, fingerprint verificada ou política equivalente. Uma assinatura válida por uma chave errada continua sendo o servidor errado.

O primeiro H não foi substituído pelo rekey

A RFC 4253 usa K e H para derivar chaves e vetores. Apenas no primeiro intercâmbio H recebe também o papel de session_id. Depois de definido, não muda enquanto a conexão existir.

O rekey pode alterar quase todo o restante. Qualquer parte pode iniciá-lo; algoritmos e host key podem mudar; chaves e vetores são recalculados; os contextos de cifra e compressão são reiniciados ao entrar em vigor SSH_MSG_NEWKEYS. Há um novo segredo e um novo hash da troca, mas não um novo identificador para as camadas superiores.

A regra não transforma mudança em irrelevância. Uma host key inesperada exige política de confiança. Um método fraco pode ser proibido. Um erro pode derrubar a conexão. A afirmação é menor: renovar com sucesso o transporte não cria uma nova autenticação de usuário nem encerra os canais existentes.

Reconectar é outra situação. A nova troca inicial produz outro identificador. Um aplicativo pode retomar uma cópia ou reatar um trabalho, porém essa continuidade funcional deve ligar duas conexões, não fingir que existe uma só sessão criptográfica.

A assinatura carregava a sessão dentro do pedido

A RFC 4252 define o que a autenticação publickey assina. A sequência começa pelo identificador da sessão e inclui o número SSH_MSG_USERAUTH_REQUEST, nome do usuário, serviço, método, booleano, algoritmo da chave e a própria chave pública.

Uma assinatura capturada na conexão A não verifica na B, porque o primeiro hash é outro. Alterar usuário, serviço, método ou algoritmo também muda a mensagem assinada. A prova afirma posse para esta solicitação neste transporte, não uma aprovação genérica reutilizável.

Mesmo assim, o servidor responde a perguntas separadas. A assinatura está correta? A chave é aceitável para a conta apresentada? A política exige outra forma de autenticação? Pode haver uma assinatura matematicamente válida e ainda faltar autorização para concluir o login.

O método hostbased acrescenta host e usuário do cliente ao mesmo vínculo. Posse da chave de uma máquina tampouco prova, sozinha, que o nome está correto ou que aquela pessoa pode entrar.

Sucesso de login não era autorização total

Depois de SSH_MSG_USERAUTH_SUCCESS, o serviço solicitado começa. Em seguida surgem decisões que não estavam disponíveis antes: abrir um shell, iniciar um subsistema, encaminhar determinada porta, expor o agente ou acessar um destino.

Essas decisões pertencem à política local. O identificador permite que as camadas digam que uma prova pertence à mesma conversa protegida. Ele não autoriza todo ato futuro dentro dela.

O limite afeta auditoria. session_id mais “publickey aceito” correlaciona a autenticação com a conexão. Sem pedidos de canal e seus resultados, não prova comandos executados, destinos liberados nem dados servidos.

Os algoritmos envelheceram sem mover a fronteira

As escolhas de 2006 não permaneceram todas adequadas. A RFC 8332 introduziu assinaturas RSA com SHA-256 e SHA-512 para autenticação do servidor e do cliente. A mesma chave RSA podia manter o formato ssh-rsa, enquanto um nome novo selecionava o procedimento de assinatura. Formato da chave, algoritmo e conteúdo assinado continuavam separados.

A RFC 9142 atualizou as recomendações de KEX e orientou a saída de métodos baseados em SHA-1. Era possível modernizar o primeiro intercâmbio sem alterar sua responsabilidade: o hash aceito no início continuava sendo a âncora de contexto para as camadas superiores.

Uma âncora fiel não corrige um começo fraco. Se o cliente confiou na host key errada ou aceitou um método inadequado, as provas posteriores ficam precisamente ligadas a esse erro. Continuidade e qualidade são propriedades diferentes.

“Identidade SSH” escondia objetos distintos

O nome do host expressa o destino pretendido. A host key é um principal criptográfico que precisa ser associado ao nome. O hash descreve uma troca. Sua primeira ocorrência identifica uma conexão. A chave do usuário prova posse para um pedido. A política autoriza operações.

Os RFCs sustentam esses significados e a evolução dos algoritmos. Não medem quantos clientes verificam chaves, se um servidor faz rekey no prazo, se SHA-1 desapareceu nem qual comando uma implantação executou.

O passo histórico do SSH foi deliberadamente estreito. As chaves podiam mudar; a conversa não esquecia a troca que a constituiu. O hash persistente virou referência, não autoridade universal.