Guias de Segurança
Não dê chaves de root a ambientes que podem ser comprometidos: menor privilégio para chaves SSH
Cadastrando uma chave SSH em produção a partir de um ambiente efêmero e comprometível (um pod de nuvem com GPU, um runner de CI)? Se ela vazar, alguém ganha root em produção. Como tornar as chaves de menor privilégio com um usuário sem root e uma chave restrita a comando, limitada a uma única operação.
Para: qualquer pessoa que alcance produção por SSH a partir de um ambiente efêmero — um pod de nuvem com GPU, um runner de CI, uma VM descartável. Nenhum passo de ataque — só tornar as chaves de menor privilégio para encolher o raio da explosão. Para a base de separar chaves, veja o checklist de base.
A visão deste site: trate ambientes efêmeros como não confiáveis
Computação descartável costuma pular o fortalecimento — é um lugar que pode ser comprometido. Colocar ali uma chave de root de produção é como deixar a cópia da chave da porta da frente na rua. Este site usa uma chave distinta por host, restringe cada uma a um propósito e remove chaves no momento em que estão sem uso (→ chaves separadas para minimizar o raio de explosão). Tratar uma chave não como "um passe prático", mas como "o ativo mais crítico que abre tudo se vazar" é, no fim, a postura mais segura.
✗ chave de root em um ambiente efêmero
ambiente comprometido → root em produção com aquela chave → alcança arquivos, segredos e outros serviços — tudo.
○ chave sem root restrita a comando
mesmo que a mesma chave vaze, ela só consegue rodar o único comando especificado. Sem shell, sem encaminhamento — o dano fica contido a uma operação.
Por que uma chave de root em um ambiente efêmero é perigosa
Ambientes efêmeros tendem a pular o fortalecimento ("vamos apagá-lo logo"), o que os torna um trampolim fácil para um atacante. Uma chave de root de produção ali maximiza o dano de uma só vez.
Digamos que você suba um pod para processamento e, para trabalhar em produção a partir dele, cadastre uma chave no authorized_keys do root. Prático — mas se esse pod for comprometido, o atacante entra em produção como root com aquela chave. Quer o ponto de entrada seja um RCE ou um vazamento de chave, a forma final é a mesma: produção tomada com uma chave roubada (relacionado: uma chave roubada via RCE e usada em cobrança fraudulenta).
Três passos para chaves de menor privilégio
Mude de "conceder poder total porque é conveniente" para "limitar o que ela pode fazer ao mínimo".
Remova a chave de root do ambiente efêmero
~/.ssh/authorized_keys de produção. Se ociosas, removê-las não tem impacto. Primeiro, elimine as "esquecidas por aí".Mesmo que precise de novo, não volte para root
Restrinja a chave a uma única operação
command="..." e restrict à linha da chave no authorized_keys. Mesmo um login bem-sucedido só consegue rodar o único comando especificado, com encaminhamento de porta e shell desativados. Um vazamento fica contido àquela única operação.# Cadastre uma chave restrita a UMA operação no authorized_keys de um usuário sem root.
# Logar com ela só consegue rodar o comando dado; encaminhamento e PTY ficam desligados.
command="/usr/local/bin/deploy-pull",restrict ssh-ed25519 AAAA...resto-da-chave-publica deploy@cirestrict desativa encaminhamento, encaminhamento de agente, PTY, X11 e mais de uma só vez; command="..." fixa a ação executável a uma só coisa. O movimento básico é uma chave restrita a um único propósito — só puxar um deploy, só rodar um script específico — criada por caso de uso.
O cenário em que as pessoas caem (perigoso)
- cadastrar uma chave no root de produção a partir de um pod/CI
- deixar chaves já cumpridas no lugar
- reutilizar uma chave em muitos hosts
- espalhar chaves que concedem um shell completo
O cenário de menor privilégio
- alcançar produção apenas como um usuário sem root
- chaves limitadas a uma operação (restritas a comando)
- separar chaves por host e propósito
- remover chaves do authorized_keys no momento em que estão sem uso
Trate uma chave reutilizada como seu ativo mais crítico
Pense em uma chave como "um passe prático" e você a reutiliza e esquece de apagá-la. Inverta: trate-a como o ativo mais crítico que abre tudo se vazar. Separe por host e propósito, mantenha as chaves de produção fora de ambientes efêmeros e sempre remova-as após o uso. Só isso já quebra a pior cadeia — um vazamento cascateando para tudo.
O que este site faz por conta própria
Este site usa uma chave dedicada por servidor e nunca reutiliza chaves. Os deploys chegam em um usuário sem root, feito para esse fim, e produção é unidirecional — "ela recebe, não sai para buscar" (→ produção só recebe). Ela não deixa chaves permanentes de computação efêmera para dentro da produção; conecta-se só quando necessário, com menor privilégio. O motivo é exatamente o deste artigo: projete o alcance de uma chave para ser pequeno com antecedência, para que um comprometimento não consiga cascatear para tudo.
Leia a seguir
FAQ
QPor que colocar uma chave de root em um ambiente efêmero é perigoso?
Ambientes efêmeros como pods de nuvem com GPU ou runners de CI são descartáveis, então o fortalecimento costuma ser pulado e eles podem ser comprometidos. Coloque ali uma chave de root para produção e, no momento em que esse ambiente é comprometido, o atacante ganha root em produção junto com a chave. Trate ambientes efêmeros como não confiáveis e mantenha as chaves de root de produção fora deles.
QE se eu ainda precisar alcançar produção a partir de um ambiente efêmero?
Não volte para root. Crie um usuário dedicado sem root e cadastre uma chave que limite o que ela pode fazer a uma única operação. No authorized_keys, uma chave restrita a comando, com a flag restrict, faz com que até um login bem-sucedido só consiga rodar aquele um comando. Um vazamento fica então contido àquela única operação.
QQual o princípio-chave para a gestão de chaves?
Trate uma chave reutilizada como seu ativo mais crítico e nunca construa um cenário em que um vazamento expõe tudo. Separe chaves por host e por propósito, e remova chaves do authorized_keys quando não forem mais necessárias. Isso impede que um único vazamento cascateie.