Certificados SSH para agentes de IA e custódia local de credenciais

Certificados SSH e custódia local de credenciais trabalham juntos. Um certificado fornece ao servidor SSH uma declaração temporária sobre uma chave pública. A custódia local mantém a credencial privada correspondente fora do contexto, dos arquivos, dos subprocessos e dos logs de um agente de IA. Tratar qualquer um deles como substituto do outro deixa uma brecha que aparece no pior momento possível.

A versão popular desse modelo diz que um certificado de 15 minutos torna tudo seguro. Não torna. Se o agente consegue ler a chave privada, ele pode continuar usando essa chave até o certificado expirar, pedir outro certificado se conseguir alcançar o serviço de emissão ou deixar uma cópia em um espaço de trabalho que sobreviva à execução. A validade curta reduz o tempo durante o qual o servidor aceita a credencial. Ela não remove a capacidade do processo que guarda o segredo.

Para agentes que podem alterar a infraestrutura, use certificados para reduzir o período aceito e use a custódia local para impedir a exposição da credencial privada. Depois, trate renovação, interrupção e revogação como um único sistema operacional. Os detalhes importam mais que o tempo de validade do certificado mostrado em um diagrama.

Um certificado limita a aceitação, não a posse

Um certificado de usuário do OpenSSH é uma chave pública assinada acompanhada de restrições. O servidor SSH verifica a assinatura da CA e confere campos como tipo de certificado, intervalo de validade, lista de principais, opções críticas e extensões. O cliente ainda precisa provar que controla a chave privada correspondente à chave pública certificada.

Essa distinção é constantemente confundida. Um certificado é material público. Você pode colocar id_ed25519-cert.pub ao lado de uma chave privada, copiá-lo para um cliente e examiná-lo livremente. O segredo continua sendo id_ed25519. Se um agente recebe esse arquivo privado, a validade curta do certificado apenas limita por quanto tempo um certificado emitido funciona. O agente ainda possui uma credencial de assinatura reutilizável.

O OpenSSH documenta o formato dos certificados em PROTOCOL.certkeys e oferece os controles usuais de criação no manual de ssh-keygen. O comando de assinatura recebe uma chave privada da CA com -s, uma string de identidade com -I, os principais permitidos com -n e uma especificação de validade com -V. Esses são dados de autorização, não metadados decorativos. O servidor precisa estar configurado para confiar na CA e interpretar os principais antes que qualquer um deles afete o acesso.

Considere dois modelos:

• No primeiro, um agente recebe id_ed25519, um certificado e o endpoint da CA. O agente pode assinar os desafios SSH por conta própria e talvez consiga fazer futuras solicitações de certificados.
• No segundo, um executor local mantém id_ed25519 em armazenamento protegido. O agente solicita uma ação SSH nomeada, e o executor cuida da autenticação SSH sem devolver material privado.

Os dois modelos podem usar o mesmo certificado. Apenas o segundo impede que uma injeção de prompt no agente, um plugin comprometido ou um subprocesso curioso copie a credencial privada.

Também não use o campo de identidade do certificado como prova de custódia. O valor de -I ajuda as pessoas a relacionar registros de emissão e acesso, mas qualquer solicitante que possa pedir certificados pode escolher uma identidade de aparência impressionante. Vincule a emissão a uma chave pública conhecida e a uma sessão conhecida do agente. Se o emissor aceitar chaves públicas e strings de identidade arbitrárias, sua trilha de auditoria se tornará fictícia sob pressão.

A custódia local muda a falha que você precisa planejar

Manter uma credencial localmente transforma um incidente de exfiltração de segredo em um incidente de autorização de ação. É um problema melhor, mas ainda é um problema. O agente pode solicitar um comando destrutivo, apontar para o host errado ou usar uma sessão aprovada por mais tempo que o operador pretendia.

O componente local deve manter a credencial SSH privada e executar a operação de protocolo por conta própria. O agente deve receber a saída do comando, o status de saída e informações de diagnóstico limitadas. Ele não deve receber a chave privada como texto, o caminho de um arquivo temporário, uma variável de ambiente, um socket de agente SSH que possa encaminhar ou um valor supostamente oculto que outra ferramenta consiga resolver.

Um compromisso ruim e comum monta um diretório de segredos como somente leitura no ambiente do agente. Somente leitura protege contra alterações, não contra leitura. Outro compromisso ruim coloca a chave privada em um agente SSH e dá a todos os processos filhos acesso a SSH_AUTH_SOCK. Isso pode ser aceitável em um shell interativo rigidamente controlado, mas um agente de programação autônomo inicia ferramentas, executores de testes, hooks de pacotes e processos auxiliares. Cada um amplia o conjunto de processos que podem pedir ao agente para assinar.

A custódia local também oferece um ponto útil para o controle humano. Uma pessoa pode aprovar a primeira ação de um novo processo, exigir aprovação para credenciais sensíveis a cada uso ou bloquear o cofre por completo. Esses controles não substituem a autorização do servidor. Eles decidem se um processo poderá tentar uma ação.

Mantenha essa fronteira estreita. O componente que guarda a chave privada não deve aceitar texto arbitrário de shell e executá-lo cegamente só porque o agente o forneceu. Ele deve conhecer o host, a conta de destino e a solicitação de ação que executará, além de registrar esses fatos antes ou junto da execução. Se você não consegue reconstruir qual processo solicitou ssh deploy@host, a custódia local virou um simples invólucro de segredo, com pouca responsabilização.

A consequência prática é direta: a renovação do certificado deve atualizar a autorização pública, enquanto a custódia local continua controlando a assinatura privada. Não recrie a credencial privada toda vez que um certificado expirar, a menos que tenha outro motivo para fazer sua rotação.

A validade do certificado deve acompanhar a tolerância a interrupções

Escolha a validade com base em quanto tempo você tolera que uma credencial já emitida continue válida depois que o trabalho novo for interrompido. A resposta muda entre uma execução de diagnóstico somente leitura, um fluxo de implantação e um agente que pode alterar controles de acesso.

Comece com uma duração que deixe espaço para o trabalho real. A renovação de certificados falha mais vezes do que as equipes esperam porque laptops entram em suspensão, rotas de VPN mudam, a CA fica temporariamente indisponível, um comando longo mantém uma conexão aberta ou o relógio da máquina se desvia. Uma validade muito curta transforma interrupções comuns em uma fonte constante de lógica de novas tentativas e atalhos perigosos.

Para muitas tarefas autônomas, um certificado válido por 15 a 60 minutos é uma primeira configuração razoável. Use o limite inferior quando a conta puder afetar sistemas de produção. Use uma janela maior somente quando o trabalho realmente precisar dela e você puder explicar o motivo. Um certificado de várias horas para um trabalho que dura dez minutos costuma ser conveniência disfarçada de necessidade operacional.

Não confunda a validade do certificado com a duração da conexão SSH. O SSH faz a autenticação quando estabelece uma conexão. Normalmente, o servidor não expulsa uma sessão já autenticada quando o certificado chega ao fim da validade. A multiplexação de conexões pode tornar isso ainda mais surpreendente: um comando posterior pode reutilizar uma conexão mestre já autenticada, em vez de fazer uma nova verificação do certificado.

Esse comportamento muda o desenho:

1. Defina a validade do certificado para limitar novas autenticações.
2. Limite separadamente a duração do comando ou da sessão no executor local.
3. Evite entregar a um agente um socket de controle multiplexado reutilizável.
4. Encerre as sessões ativas durante uma emergência quando a própria ação precisar parar.

A opção ControlMaster do ssh_config é útil para agilizar o uso interativo, mas enfraquece suposições simples sobre autenticação por comando. Para trabalhos autônomos, desative a multiplexação em destinos sensíveis ou faça o executor assumir o controle e encerrar a conexão. Não deixe um agente herdar um caminho de controle que continue autenticado depois que a aprovação ou a janela do certificado deveria ter terminado.

A disciplina do relógio também pertence a esta seção. Um certificado tem um intervalo absoluto de validade. Se o host emissor e o servidor de destino divergirem significativamente no horário, um certificado recém-criado pode parecer expirado ou ainda não válido. Monitore a sincronização de tempo nos dois lados e falhe de forma segura quando o servidor rejeitar a janela de validade. Não contorne uma falha de relógio emitindo um certificado muito mais longo.

A renovação precisa provar que a mesma fronteira de custódia continua existindo

Um serviço de renovação deve emitir um novo certificado somente depois de vincular a solicitação à credencial mantida localmente, à sessão atual do agente e ao escopo de autorização solicitado. Aceitar uma chave pública em uma solicitação HTTP não prova nada sobre quem controla a metade privada correspondente.

O fluxo mais limpo pede que o executor local prove, durante a renovação, que possui a chave pública registrada. O emissor verifica essa prova, confere a sessão ativa e o principal solicitado, assina a chave pública e devolve apenas o certificado público. O executor associa esse certificado à credencial privada que mantém internamente para a próxima conexão SSH.

Um comando de criação de certificado no emissor poderia ser assim:

ssh-keygen -s agent_user_ca -I run-4821 -n deploy-prod -V +30m agent-run-4821.pub

Esse comando assina agent-run-4821.pub com a chave privada da CA. Ele cria um certificado público correspondente, normalmente chamado agent-run-4821-cert.pub. A string run-4821 ajuda a relacionar os registros, deploy-prod é o principal permitido e +30m solicita um intervalo de trinta minutos. O emissor deve gerar essa string de identidade por conta própria, em vez de confiar em um rótulo fornecido pelo agente.

Inspecione cada certificado novo antes de deixar a automação depender dele:

ssh-keygen -L -f agent-run-4821-cert.pub

A saída lista o tipo do certificado, a impressão digital da CA assinante, a identidade, o número de série, o período de validade, os principais, as opções críticas e as extensões. Inclua essa inspeção nos testes do emissor. Um principal ausente, um período de validade que começa no futuro ou uma extensão inesperada acabará aparecendo como uma implantação malsucedida, fazendo alguém procurar uma chave alternativa de longa duração.

Renove antes que o trabalho precise de uma nova conexão SSH, não no segundo exato da expiração. O executor pode solicitar uma substituição perto do fim do intervalo, enquanto o certificado atual ainda funciona. Ele também deve se recusar a iniciar um comando se restar pouco tempo de validade para a duração permitida do comando. Essa verificação impede que um trabalho comece uma gravação importante pouco antes de a próxima autenticação falhar.

Mantenha a renovação idempotente no nível da solicitação. Uma resposta perdida pode fazer o cliente tentar novamente mesmo que o emissor já tenha criado um certificado válido. Registre um identificador da solicitação, um identificador da sessão, a impressão digital da chave pública, o principal e a expiração. Em uma nova tentativa, devolva o certificado emitido anteriormente quando os dados coincidirem. Se forem diferentes, rejeite a solicitação em vez de adivinhar qual solicitação o agente quis fazer.

Os principais e a política do servidor decidem o que o certificado pode fazer

Um certificado informa quem pode se autenticar. O servidor ainda decide qual conta local aceita essa identidade e o que essa conta pode fazer. Se você permitir que um certificado de agente se autentique como uma conta administrativa compartilhada e ampla, uma validade curta não compensará uma decisão de autorização permissiva.

O OpenSSH pode confiar em uma CA de usuários por meio de TrustedUserCAKeys. Depois, você pode mapear os principais aceitos com AuthorizedPrincipalsFile ou AuthorizedPrincipalsCommand. A segunda opção é útil quando o servidor precisa de um mapeamento de contas administrado centralmente, mas acrescenta uma dependência de disponibilidade ao login. Um arquivo estático de principais é menos flexível e muitas vezes mais fácil de entender em uma frota pequena.

Uma configuração de servidor restrita pode ser assim:

TrustedUserCAKeys /etc/ssh/agent_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
RevokedHostKeys /etc/ssh/revoked_agent_credentials.krl

Para uma conta local chamada deploy, /etc/ssh/auth_principals/deploy poderia conter apenas:

deploy-prod

Esse arranjo significa que o servidor aceita um certificado da CA nomeada somente quando ele contém deploy-prod como principal e não foi revogado pela KRL configurada. Teste a versão exata do OpenSSH em seus servidores. As diretivas de configuração e o comportamento dos certificados são estáveis em princípio, mas os pacotes das distribuições e as versões antigas podem afetar aquilo em que você pode confiar.

As opções críticas e as extensões do certificado podem restringir ainda mais o uso. O OpenSSH oferece suporte a opções críticas como force-command e source-address. Ele também reconhece extensões como permit-pty, permit-port-forwarding e permit-agent-forwarding. Use-as quando o fluxo de trabalho de destino tiver um formato restrito. Um agente que só executa um auxiliar de implantação não deve receber por acidente um shell interativo geral.

Não coloque uma capacidade genérica de permit-pty em um certificado de agente só porque alguém talvez precise fazer uma investigação depois. Em vez disso, emita uma credencial de diagnóstico separada e aprovada conscientemente quando ela for necessária. Extensões convenientes tendem a permanecer muito tempo depois da tarefa excepcional que as justificou.

A revogação de emergência exige mais que esperar a expiração

A validade curta ajuda na contenção rotineira. Se você interromper a emissão e o certificado expirar em trinta minutos, novas autenticações SSH pararão depois desse período. Isso pode ser suficiente quando você identifica uma tarefa incorreta antes que ela alcance um destino sensível. Não é suficiente quando uma credencial privada pode ter escapado ou quando um agente começou a causar danos.

Sua primeira ação de contenção é interromper a emissão para a sessão, a credencial ou a CA relevante. Depois, impeça que as credenciais já emitidas se autentiquem nos locais em que a urgência exigir. No OpenSSH, uma Key Revocation List, ou KRL, permite que os servidores rejeitem certificados, chaves públicas ou uma CA assinante específicos.

Para adicionar um certificado emitido a uma KRL, um operador pode usar um comando como este:

ssh-keygen -k -f revoked_agent_credentials.krl -s agent_user_ca.pub agent-run-4821-cert.pub

O argumento -s identifica a CA que assinou o certificado. Distribua a KRL resultante aos servidores de destino, mantenha o caminho consistente com RevokedHostKeys e recarregue o sshd de acordo com seu procedimento operacional. Teste todo o fluxo com antecedência: crie um certificado, autentique com sucesso, adicione-o à KRL, distribua o arquivo, recarregue o sshd e confirme que uma nova autenticação falha.

Uma KRL não é um botão central de desligamento. Cada servidor SSH precisa receber e ler o arquivo. Se um host estiver inacessível, offline ou sob um regime de configuração separado, ele poderá continuar aceitando o certificado até a expiração. Por isso, um intervalo de validade curto continua sendo útil mesmo quando você opera listas de revogação.

Quando houver suspeita sobre a própria chave privada da CA, revogar certificados individuais não é uma resposta na escala correta. Remova ou substitua a confiança nessa CA nos servidores afetados, emita uma nova CA e recertifique somente as credenciais nas quais você ainda confia. Mantenha uma CA distinta para o acesso dos agentes, para que essa operação não bloqueie o acesso emergencial humano. Mantenha um caminho de emergência testado, mas fora do alcance do agente, e registre seu uso.

Por fim, encerre as sessões ativas. A distribuição da KRL bloqueia autenticações futuras, mas não necessariamente encerra uma conexão SSH que o servidor já aceitou. Use os controles de sessão do host, o supervisor de trabalhos ou os controles de rede para interromper o trabalho em andamento. Depois, revise os comandos já executados, pois a revogação da credencial não desfaz uma implantação nem restaura um arquivo excluído.

Um emissor de certificados precisa falhar de forma segura durante incertezas

O emissor deve rejeitar a renovação quando não puder verificar a identidade do executor local, o estado da sessão, o principal solicitado ou a autorização necessária para aquele escopo. A pressão por disponibilidade faz as equipes transformarem essas verificações em avisos. Essa decisão converte uma indisponibilidade temporária em emissão ilimitada de credenciais.

Planeje os casos comuns de falha antes do dia da implantação. Se o emissor estiver inacessível, permita que um certificado existente funcione até sua expiração normal, mas não o substitua silenciosamente por uma chave privada estática. Se o cofre local estiver bloqueado, negue a ação. Se uma aprovação humana for necessária e ninguém responder, encerre o trabalho em vez de permitir que o agente retenha uma aprovação indefinidamente.

Um registro de renovação útil inclui a impressão digital da CA, o número de série do certificado, o horário de emissão, o horário de expiração, a impressão digital da chave pública, o principal solicitado, a identidade do processo do agente, o identificador da sessão, a classe do destino e o resultado da aprovação. O próprio certificado contém parte dessas informações, mas não informa se a solicitação seguiu o caminho de controle local planejado.

O emissor também deve impedir mudanças de escopo durante a renovação. Uma sessão aprovada para deploy-prod não deve ser renovada para root-prod, um principal mais amplo, apenas porque o agente revisou seu plano. Exija uma nova fronteira de autorização para uma conta, um grupo de destinos ou uma classe de comandos diferente. É nesse ponto que trabalhos autônomos de longa duração costumam se tornar inseguros: a sessão começa restrita e depois acumula exceções por meio de uma lógica de renovação que ninguém revisa.

Use registros separados para emissão e execução. A emissão prova que a CA autorizou um certificado. Os logs do servidor SSH e os registros de atividade do executor provam onde uma credencial foi usada e qual comando foi executado. Você precisa dos dois quando um operador perguntar se um certificado foi emitido indevidamente ou emitido corretamente, mas usado de forma indevida.

Teste a revogação como um exercício operacional cronometrado

Um runbook que diz para revogar o certificado está incompleto até nomear os sistemas, os arquivos, os direitos de acesso, a falha esperada e a pessoa que pode agir quando o emissor estiver indisponível. Faça o exercício em um destino que não seja de produção, com certificados reais e o mesmo mecanismo de distribuição usado em produção.

Use esta sequência:

1. Emita um certificado com um número de série conhecido e um intervalo curto e documentado.
2. Faça uma autenticação e registre o evento de aceitação no servidor.
3. Desative a renovação para a sessão do agente associada.
4. Adicione o certificado à KRL, distribua-a e recarregue as instâncias do sshd nos destinos.
5. Tente uma nova conexão SSH e confirme que o servidor a rejeita. Em seguida, encerre a sessão ativa original, caso exista.

Meça o tempo real entre a solicitação de contenção e a rejeição em cada grupo de servidores. Não divulgue um número-alvo que você nunca tenha observado. O resultado depende da rapidez com que seu sistema de configuração entrega a KRL e da confiabilidade com que recarrega o sshd.

Teste também os casos desconfortáveis. Revogue um certificado quando um host de destino estiver inacessível. Revogue-o durante uma conexão multiplexada existente. Revogue-o enquanto a máquina local estiver suspensa e a renovação não puder ser concluída. Revogue-o depois que um operador tiver aprovado uma sessão, mas antes do primeiro comando. Cada resultado mostra se seus controles bloqueiam a emissão, uma nova autenticação ou a execução ativa. São controles diferentes, e chamar todos eles de revogação cria suposições perigosas.

Guarde as evidências do exercício. Mantenha o certificado emitido, a atualização da KRL, o registro do executor e o log de rejeição do servidor de destino. Quando ocorrer um incidente real, esse conjunto dará aos responsáveis um caminho de comandos verificado, em vez de um documento que envelheceu até virar apenas uma esperança.

Mantenha aprovação, auditoria e acesso SSH conectados

A aprovação humana só é útil quando está associada ao processo que a utilizará. Aprovar um processo em segundo plano sem nome é um convite para aprovar a coisa errada. O revisor deve ver quem assinou o processo, qual sessão está sendo iniciada e se a credencial SSH solicitada tem um escopo comum ou sensível.

O Sallyport mantém as credenciais SSH em seu cofre local criptografado e executa o SSH por meio de seu auxiliar integrado, para que um agente compatível com MCP não precise ter a chave SSH privada em seu próprio ambiente. Seus diários de sessão e atividade podem conectar uma aprovação humana ao processo do agente e aos registros de ações posteriores.

A trilha de auditoria precisa de evidências contra adulteração, além de uma visualização conveniente. O Sallyport projeta seus diários a partir de um log de auditoria criptografado e encadeado por hash, e sp audit verify permite que um operador verifique essa cadeia offline sem precisar acessar o cofre. Execute essa verificação durante a análise de incidentes e ao exportar evidências. Uma lista legível de atividades, sozinha, não prova que ninguém removeu um evento inconveniente.

Não torne o sistema de auditoria responsável por uma política de acesso que ele não aplica. O servidor SSH ainda precisa confiar na CA correta, aceitar somente os principais pretendidos, ler a KRL atual e restringir a conta de destino. O executor local ainda precisa proteger as credenciais privadas e solicitar as aprovações definidas por você. Os logs fornecem evidências e retorno operacional. Eles não corrigem uma conta com permissões excessivas.

A melhor medida inicial não é reduzir a duração do certificado. Faça um inventário das ações do agente que precisam de SSH, dê a cada uma um principal e uma conta restritos, coloque a credencial privada sob custódia local e ensaie o caminho que interrompe a emissão, distribui a revogação e encerra as sessões ativas. Quando isso funcionar, escolha o período de validade mais curto que seu sistema de renovação real consiga sustentar.