termalA forma segura de dar a um modelo local acesso SSH é nunca dar uma chave a ele. Faça com que ele chame uma ferramenta — um servidor MCP atuando como custodiante — que guarda as chaves (ou emite certificados de curta duração), alcança apenas os hosts que você listou, aplica uma lista de comandos permitidos por host e registra cada um. Aí um prompt sequestrado só consegue pedir uma ação pelo custodiante; não consegue assumir a sua identidade nem alcançar um host que você não listou. O que as pessoas erram primeiro: rodar o modelo no seu próprio hardware protege os seus prompts, não os seus servidores — “é local, então é seguro” não é verdade e não faz nada quanto ao que acontece quando esse modelo ganha um shell.
Os modelos locais estão em alta. O Ollama numa estação de trabalho, um modelo de pesos abertos atrás do seu próprio endpoint, um agente de código auto-hospedado — você os roda por bons motivos: privacidade, custo, sem limites de taxa, funciona num avião. E quando um modelo já está cuidando dos seus prompts, o passo óbvio seguinte é apontá-lo para a sua infraestrutura: deixar que ele acompanhe um log, reinicie um serviço, rode a migração — e é aí que cai a pergunta de verdade.
Por que “local” não torna o acesso ao servidor seguro
Duas coisas continuam exatamente tão perigosas quer o modelo rode em um datacenter, quer na máquina embaixo da sua mesa.
A chave continua sendo uma credencial ao portador. Jogue o id_ed25519 no ambiente do agente para que ele mesmo rode o ssh, e quem — ou o que — segurar esses bytes é você, em todo host que confia na chave. Rodar o modelo localmente não muda isso; só move a cópia para uma máquina que por acaso é sua. E você ainda não consegue voltar atrás: uma vez que a chave passou pelo contexto do modelo — uma variável de ambiente, um arquivo montado, uma chamada de ferramenta, uma transcrição — você já não consegue provar que ela não foi parar onde não devia. A única resposta honesta para “o modelo viu a minha chave?” é rotacioná-la em todo host.
Um modelo local também se confunde. Injeção de prompt não precisa de um modelo na nuvem. Uma linha de log envenenada, um nome de arquivo malicioso, um resultado de ferramenta armadilhado, um plano ansioso demais — um modelo local age sobre todos eles com a mesma facilidade de um hospedado. Se é que há diferença, o risco é pior, porque as pessoas confiam mais nas configurações locais, montam-nas com menos salvaguardas e dão a elas acesso mais amplo, justamente porque “está na minha máquina”. Esse é o instinto errado: o julgamento do modelo não é melhor por os pesos serem locais.
Então o objetivo é o mesmo de qualquer agente — deixar o modelo fazer o trabalho sem nunca segurar a credencial, e tornar cada ação restrita, visível e reversível.
Três jeitos de fazer isso mal
Colar a chave crua. A rota direta, e a pior: sem escopo, sem validade e com a irreversibilidade lá de cima. A chave que faz deploy na staging normalmente também alcança o banco de dados de produção a dois saltos de distância.
Emitir um token de longa duração. Um token de deploy ou uma credencial de “automação” que nunca expira. Parece mais organizado que uma chave, mas é o mesmo problema da credencial ao portador com passos a mais. Se revogar algo depende de lembrar que ele existe, vai sobreviver ao experimento que o criou.
Dar a ele um login root próprio e sair de perto. O instinto certo — uma identidade separada — feito do jeito errado. Jogue uma chave pública no authorized_keys de um usuário bot e você construiu um acesso sem nenhuma trilha de auditoria: nada distingue os comandos do modelo dos de qualquer outro, e quando algo quebra às 2 da manhã você está reconstruindo a sessão dele a partir do histórico do bash e de achismo.
O fio condutor: o modelo guarda uma credencial permanente, e a observabilidade fica em segundo plano.
O padrão que funciona: um custodiante, não uma cópia
Inverta. O modelo nunca deveria segurar a credencial, ponto.
- O modelo pede; um custodiante assina. Um intermediário guarda as chaves (ou emite certificados de curta duração) e autentica em nome do modelo. Comprometa o contexto do modelo e você ganha a capacidade de pedir ações pelo intermediário — não a de se passar por você de qualquer lugar.
- O escopo é explícito. O modelo alcança apenas os hosts que você listou. Um host novo é uma nova decisão, não um padrão.
- Os comandos são fiscalizados. Por host, decida se o modelo recebe um shell completo, uma lista de comandos permitidos ou nada — para que “reiniciar o nginx” seja permitido na camada web e “qualquer coisa” nunca seja.
- Um humano pode acompanhar — ao vivo. Não só no post-mortem, e com o registro distinguindo “foi o modelo que fez isso” de “fui eu que fiz isso”.
- A revogação é uma opção, não uma rotação. Como nada foi compartilhado, desligar o acesso não custa nada.
Nada disso é exótico — é mais ou menos como o SSH baseado em certificados já funciona em times de infraestrutura sérios. O problema sempre foi que montar isso por conta própria é um projeto, então as pessoas pulam para uma das opções ruins lá de cima.
Ligando isso a um modelo local
O MCP — o Model Context Protocol — é a forma limpa de fazer isso, e é agnóstico ao cliente: qualquer cliente compatível com MCP pode conduzi-lo, então não importa se o seu modelo é o Claude, um modelo de pesos abertos atrás do Ollama ou algo que você mesmo hospeda.
- Rode o seu modelo local por um cliente compatível com MCP (um agente de código ou cliente de chat que fale MCP).
- Aponte-o para um servidor MCP que faz a ponte para o SSH — um que autentica em nome do modelo em vez de lhe entregar uma chave.
- Ligue apenas os hosts que você quer e defina a política de comandos de cada host (total / lista de comandos permitidos / bloqueado).
- Mantenha a sessão à vista e deixe-a escrever em um registro de auditoria, para que cada comando que o modelo roda seja atribuível e reproduzível.
O modelo ganha ferramentas — abrir uma sessão, rodar um comando, ler ou gravar um arquivo — e o custodiante faz a autenticação. A sua chave nunca entra no ambiente do modelo, na sua máquina ou em qualquer outro lugar. E porque é o custodiante que guarda a credencial, e não o modelo, a mesma montagem vale no momento em que você parte para um agente hospedado — o Claude Code por SSH e o OpenAI Codex por SSH usam exatamente este padrão com um modelo na nuvem do outro lado.
Como o Termalin faz isso
O Termalin é um cliente SSH com um servidor MCP integrado, então esse padrão é o comportamento normal, não um projeto.
- Na sua máquina, registre o servidor local incluído com o seu agente (
claude mcp add termalin -- <path>/termalin-mcp, ou o equivalente para qualquer cliente MCP). O modelo alcança apenas os hosts que você habilitar — o acesso do agente vem desativado por padrão — e a autenticação passa pela custódia de chaves do Termalin: você desbloqueia as suas chaves uma vez, o Termalin assina em nome do modelo, e nunca há um arquivo de chave para o modelo ler. - Por host, você define a política — acesso total, uma lista de comandos permitidos ou bloqueado — para que um modelo local que se confunda não consiga rodar algo que você nunca autorizou naquela máquina.
- Você vê acontecer. As sessões do agente rodam como abas de terminal ao vivo; a grade de monitoramento as espelha, e os blocos que um modelo está conduzindo brilham. Cada comando é marcado na gravação de sessão — apenas a saída, nunca as suas teclas — e escrito em um registro de auditoria com o dispositivo e o IP de onde veio.
- Sem o app aberto? Aponte o modelo para o endpoint MCP hospedado do Termalin com uma chave de API restrita a servidores específicos, com uma validade, com política de comandos, que autentica cada execução com um certificado de curta duração — de modo que até uma chave vazada não consegue alcançar um host fora da lista nem rodar fora dos comandos permitidos a ela.
De um jeito ou de outro, a propriedade que você queria se mantém: o seu modelo local consegue operar os seus servidores, e nunca viu uma chave.
Comece com um host sem graça
Não comece pela produção. Cadastre uma máquina de baixo risco — um servidor de staging, um VPS de brincadeira —, deixe-a com uma lista de comandos permitidos e dê ao modelo uma tarefa de verdade: acompanhar o log até o erro aparecer, corrigir a configuração, reiniciar o serviço. Mantenha a grade aberta enquanto ele trabalha. O que você aprende na primeira hora — como ele se comporta, onde ele hesita, o que faz com a ambiguidade — diz se o segundo host entra, e com quanta corda.
Essa é a recompensa silenciosa do modelo de custódia: você amplia um host por vez, porque nenhum passo que você dá é um que não possa desfazer — não importa onde o modelo esteja rodando.
O Termalin é um cliente SSH gratuito e multiplataforma com um servidor MCP integrado, uma custódia de chaves e política de agente por host — baixe-o ou leia como ele lida com as chaves com segurança.