Resumo

  • O RFC 9987 define um agente que guarda chaves privadas e atende pedidos para listar, carregar, remover, bloquear e assinar. O protocolo básico não autentica o cliente nem protege o transporte; alcançar o endpoint costuma ser a permissão operacional.
  • O encaminhamento não copia o material secreto para o host remoto. Ele estende até esse host a possibilidade de pedir operações privadas, criando a confiança transitiva que o próprio RFC recomenda não habilitar por padrão.
  • Vida útil, confirmação e restrições de extensão reduzem o uso. O servidor de destino ainda decide se a chave autentica a conta, se a assinatura é válida, se outro fator é necessário e quais ações serão permitidas.

Suponha que um operador carregue uma chave por dez minutos e exija confirmação para cada assinatura. A inspeção inicial mostra o estado correto. Minutos depois, outra ferramenta adiciona a mesma chave sem as restrições. Pelo RFC 9987, o agente deveria substituir as condições anteriores pelas novas ou rejeitar a duplicata.

Se aceitar a substituição, a mesma impressão digital passa a representar outra capacidade operacional. O arquivo da chave não mudou. O grafo de autorização mudou.

Esse exemplo revela por que a segurança do agente não pode ser descrita apenas com adjetivos como “protegido”, “temporário” ou “confirmado”. Restrições são estado executado. Elas nascem, mudam, expiram e precisam ser lidas após cada transição.

O segredo fica, a função atende

O RFC 9987, publicado em maio de 2026 como Proposed Standard, descreve um protocolo de requisição e resposta dirigido pelo cliente. O agente não envia mensagens espontâneas. Clientes podem consultar identidades, carregar e remover chaves, travar o serviço e solicitar assinaturas. O agente pode recusar tipos de chave, flags ou operações.

Separar o agente do cliente traz vantagens reais. A chave desencriptada não precisa habitar cada processo SSH. Um componente menor pode bloquear dumps e depuração, isolar módulos de token e reduzir a exposição. Uma chave de hardware pode continuar não exportável.

Mas o protocolo não traz autenticação própria nem segurança de transporte. Em Unix, permissões do socket e credenciais do processo par limitam o acesso; no Windows, um descritor protege o named pipe. SSH_AUTH_SOCK normalmente aponta para o endpoint.

Quem alcança esse endpoint pode, em geral, invocar operações privadas. O RFC separa explicitamente dois riscos: roubar uma cópia da chave e roubar o uso da chave. Um módulo físico pode resolver muito bem o primeiro sem encerrar o segundo.

No pedido de assinatura, o cliente fornece o blob público, os dados e flags. Uma resposta de sucesso prova que o agente produziu uma assinatura. Não prova que o processo tinha mandato, que o conteúdo representava um destino aprovado, que o servidor aceitou a conta ou que algum comando ocorreu.

Restrições têm escopo e tempo

A restrição de vida útil pede que o agente apague a chave após certo número de segundos desde o carregamento. Ela encerra pedidos futuros naquele agente. Não revoga assinaturas emitidas, não fecha sessões já aceitas e não reverte alterações feitas remotamente.

A restrição de confirmação exige consentimento explícito por operação privada. O protocolo não padroniza a interface nem as informações mostradas. Um aviso que apresenta destino, conta e contexto oferece evidência melhor que uma pergunta genérica baseada no comentário da chave. Uma tempestade de confirmações pode produzir fadiga e aprovações automáticas.

Restrições de extensão permitem regras próprias de implementações. Se o agente não entende uma restrição, deve abortar, rejeitar a chave e falhar fechado. Ignorar silenciosamente o limite seria perigoso. Mesmo assim, cliente e agente precisam compartilhar a extensão, e testes devem mostrar que ela realmente filtra o uso.

O recarregamento é a transição menos observada. Um script de inicialização, uma sessão nova ou outra ferramenta podem alterar as restrições da mesma chave. O inventário deve guardar o evento e o estado resultante, não apenas a intenção original.

Travar o agente suspende operações sensíveis até a senha correta. Isso não revoga um login já concluído. A linha do tempo local não comanda retroativamente o servidor remoto.

Encaminhamento é delegação transitiva

O agente pode ser encaminhado por uma conexão SSH. O host intermediário expõe um socket, e as mensagens retornam ao agente do cliente por um canal. O segredo não atravessa a conexão; o direito prático de pedir uma assinatura atravessa.

O RFC chama esse arranjo de confiança transitiva. Recomenda que implementações não encaminhem por padrão e que usuários não o façam para hosts que não sejam plenamente confiáveis. Sem controles extras sobre visibilidade e uso em conexões encaminhadas, a escolha vira tudo ou nada.

Confiar no bastion significa mais do que validar a chave do host. Significa confiar em processos privilegiados, administradores, plugins, cargas vizinhas, cadeia de atualização e capacidade de detectar intrusão. Um servidor criado para concentrar entrada pode concentrar também acesso a agentes de vários operadores.

A atribuição exige cuidado. Uma conexão SSH pode multiplexar várias sessões e conexões concorrentes ao mesmo agente. agent-connect não informa qual session channel originou o pedido. O cliente pode aceitar uma conexão autorizada sem solicitação prévia de sessão e pode continuar aceitando depois que a sessão inicial fecha.

Logo, não basta dizer “a assinatura ocorreu durante aquele shell”. É preciso unir conexão externa, pedido de encaminhamento, canal do agente, chave, restrições, assinatura e autenticação de destino.

O servidor decide se a assinatura vira acesso

Na autenticação SSH por chave pública, o RFC 4252 vincula a assinatura ao identificador da sessão, usuário, serviço, método, algoritmo e chave. O servidor verifica separadamente se a chave é um autenticador permitido para aquela conta e se a assinatura é correta. Pode exigir outros métodos.

Uma assinatura capturada não é uma senha universal. Porém, um atacante com acesso vivo ao agente pode pedir outra assinatura para uma nova sessão bem formada. Impedir replay não elimina o abuso de uma capacidade online.

Devem permanecer distintos: chave carregada; endpoint alcançável; operação aceita pelo agente; contexto assinado; chave e assinatura aceitas pelo servidor; canal autorizado; efeito observado. Cada transição tem dono e prova próprios.

Algoritmos também formam conjuntos diferentes. O agente pode suportar RSA ou Ed25519; flags podem pedir RSA/SHA-2; o servidor e a política da empresa podem aceitar menos. O registro IANA coordena nomes, mas não comprova habilitação ou conformidade local.

O que registrar

Na origem, registrar processo do agente, permissões e identidade do par, impressão digital, horário de carga, restrições efetivas, lock e remoção. Para tokens, registrar o provedor carregado e seu isolamento, pois carregar bibliotecas amplia a superfície de código.

No encaminhamento, registrar conexão SSH, confiança no host, pedido, canais e encerramento. Procurar conexões que sobrevivem à sessão e diferenciar configuração explícita, herdada ou tentativa oportunista.

Na operação, guardar horário, chave, algoritmo, uma impressão segura do contexto, decisão de cada restrição e o que a confirmação apresentou. No destino, correlacionar conta, chave autorizada, resultado, fatores extras, canais e limitações.

Por fim, observar o efeito e a terminação. Remover a chave, fechar agente e canais, retirar autorizações quando necessário e provar que uma nova tentativa falha. A ausência de cópia secreta é uma boa notícia; não é uma conclusão sobre tudo que aconteceu.