Nesta semana recebemos, em anexo de e-mail, algo que jamais deveria trafegar pela internet: uma chave privada SSH.
O contexto é corriqueiro em qualquer datacenter. Um cliente indica uma pessoa para trabalhar em um servidor e nós, como sempre, solicitamos a chave pública SSH para cadastro. É um procedimento simples, documentado e padrão da indústria há quase três décadas. A resposta veio com a chave errada — a privada. E isso muda tudo.
SSH em dois minutos
O SSH usa criptografia assimétrica: um par de chaves matematicamente relacionadas, com papéis opostos.
A chave pública funciona como um cadeado. Você pode distribuí-la à vontade: registrá-la em servidores, publicá-la no seu perfil do GitHub, enviá-la por e-mail. Quem possui o cadeado consegue trancá-lo, mas ninguém abre nada com ele. No servidor, ela é cadastrada no arquivo authorized_keys e passa a significar: “quem provar que possui a chave correspondente pode entrar”.
A chave privada é a chave física desse cadeado. Ela nunca sai da sua máquina. Não vai por e-mail, não vai por mensageiro, não vai por pendrive “só dessa vez”. É ela que prova, criptograficamente, que você é você. Quem tem a sua chave privada é você para todos os efeitos: entra nos servidores como você, age como você, responde como você.
Enviar a chave privada é o equivalente digital de despachar pelo correio a chave da sua casa — com o endereço gravado no chaveiro.
Por que isso é grave
E-mail não é canal seguro. Uma mensagem atravessa servidores intermediários, fica copiada em caixas de saída e de entrada, em backups automáticos, em sistemas antispam e antivírus corporativos. No momento em que uma chave privada é anexada a um e-mail, ela sofre o que classificamos como exposição de terceiro nível: saiu do controle do titular, transitou por infraestrutura de terceiros e chegou a destinatários que jamais deveriam possuí-la. Torna-se impossível auditar quantas cópias existem e onde estão.
Uma chave privada exposta não “volta a ser secreta”. O único procedimento correto é revogá-la imediatamente — removendo a chave pública correspondente de todos os authorized_keys onde foi cadastrada —, gerar um novo par em máquina confiável, protegido por passphrase, e enviar para cadastro apenas a nova chave pública. Foi exatamente o que orientamos, no mesmo minuto.
O problema não é o anexo errado; é o modelo mental
Errar um anexo acontece com qualquer um. Mas quem envia a chave privada acreditando ter enviado “a chave SSH” não errou um clique: demonstrou não compreender o fundamento da ferramenta cujo acesso solicita. E SSH não é uma ferramenta qualquer — é a que abre acesso administrativo a uma infraestrutura compartilhada por outras organizações.
É como entregar um paraquedas a alguém apenas porque essa pessoa acha que sabe saltar. A boa vontade não amortece a queda — nem a dela, nem a de quem estiver embaixo.
Dunning-Kruger ronda o nosso setor
Em 1999, os psicólogos David Dunning e Justin Kruger descreveram o efeito que hoje leva o nome deles: quem sabe pouco sobre um assunto tende a superestimar drasticamente a própria competência, precisamente porque lhe falta o conhecimento necessário para enxergar os próprios erros. Quem não sabe, não sabe que não sabe.
Poucos setores sofrem tanto com isso quanto tecnologia e comunicação. As ferramentas parecem acessíveis, os tutoriais estão a um clique, e a distância entre “fiz funcionar” e “entendo o que fiz” fica invisível para quem está no primeiro degrau da escada. O agravante, neste caso, é que todo o conteúdo necessário para aprender SSH corretamente é público, gratuito, abundante e disponível em português. O man ssh-keygen vem instalado em qualquer sistema. Não estamos falando de conhecimento esotérico; estamos falando de não querer estudar o básico antes de pedir acesso privilegiado.
A cadeia de confiança
Infraestrutura compartilhada é uma corrente: a resistência do conjunto é a do elo mais fraco. Cada credencial cadastrada em um servidor é um elo novo. Quando cadastramos a chave de alguém, não estamos apenas confiando nessa pessoa — estamos pedindo que todos os demais usuários da infraestrutura confiem nela também. Uma falha na base dessa cadeia não compromete um indivíduo: compromete o coletivo inteiro.
Por isso, para um datacenter solidário e cooperativo, um episódio como este é especialmente sério. A confiança é o nosso ativo central — e justamente por isso ela não pode ser presumida: precisa ser demonstrada e verificável. Solidariedade não é ausência de critério. Acolher não significa entregar acesso privilegiado a quem prova, no primeiro gesto, que ainda não domina o instrumento. Ter o coração aberto não nos autoriza a ser negligentes com a segurança de todos os que dependem da mesma infraestrutura.
VLANs isolam a rede — não o metal
Aqui vale escancarar o nosso modelo de ameaça. Nossa infraestrutura é segmentada em VLANs: o tráfego de cada cliente vive na sua própria rede lógica, invisível para as demais. Isso resolve o isolamento de rede — e somente ele.
Porque, na camada de baixo, máquinas virtuais e containers de clientes diferentes muitas vezes compartilham o mesmo servidor físico: o mesmo bare metal, a mesma CPU, a mesma memória, o mesmo hipervisor — e, no caso de containers, o próprio kernel. Para quem está do lado de fora, a VLAN é uma muralha. Para quem já tem um shell dentro de um guest, a rede deixa de ser o caminho: a superfície de ataque passa a ser a fronteira com o host — as chamadas de sistema, os dispositivos virtualizados, a microarquitetura do processador.
E a história dessa fronteira é uma história de quedas periódicas. O VENOM (CVE-2015-3456) permitiu escapar de uma máquina virtual pelo controlador de disquete do QEMU. Dirty COW (CVE-2016-5195) e Dirty Pipe (CVE-2022-0847) entregaram escalada de privilégio no kernel — o mesmo kernel que containers compartilham com o host. Spectre, Meltdown e a família de ataques de canal lateral (L1TF, MDS) mostraram que até o silício vaza segredos entre vizinhos. A pergunta nunca é se a próxima falha de escape virá, mas quando — e qual será a janela entre a publicação do CVE e o patch aplicado. Dado tempo suficiente, os CVEs sempre ganham.
Por isso, um shell SSH nas mãos de quem não entende o que faz não ameaça apenas o servidor daquela pessoa. Em infraestrutura compartilhada, escalar de uma VM para o bare metal é escalar para todas as VMs daquele metal. A parede vai cair um dia; segurança de verdade é decidir, com antecedência, o que vai existir do outro lado da parede quando ela cair.
Nossa resposta: arquitetura de contenção, não punição
É esse modelo de ameaça que define a nossa política para acessos ainda não confiáveis — e ela é arquitetura, não improviso.
Primeiro: quem ainda não demonstrou competência não compartilha kernel com ninguém. Nada de container — o ambiente vai para uma máquina virtual completa (KVM), onde a fronteira com o host é o hipervisor, uma superfície de ataque muito menor e mais auditável do que a interface inteira de chamadas de sistema de um kernel compartilhado.
Segundo: essa VM não roda no mesmo metal que as cargas de produção. Ela é provisionada em uma zona de quarentena — nós físicos dedicados, fora do cluster de produção, que não hospedam mais nada e não guardam credencial alguma do restante da infraestrutura. Ali operamos sob premissa de violação (assume breach): se um dia um escape de VM acontecer, o atacante aterrissa em um host sacrificável, num beco sem saída. Os domínios de segurança são desenhados sobre fronteiras físicas, não apenas lógicas; as VLANs continuam valendo por cima, como mais uma camada.
Terceiro: o ambiente de quarentena não é uma migração artesanal feita às pressas a cada incidente — é provisionado em minutos a partir de um template endurecido, com o painel web de administração já instalado e recursos limitados ao necessário para a tarefa. Os dados entram por canal controlado. O ambiente é descartável e reconstruível: ninguém carrega para a quarentena o passivo do ambiente anterior.
Quarto: o acesso acontece pelo painel web, com ações registradas — não por shell direto. E, como os CVEs sempre ganham no tempo, a disciplina de atualização de kernel, hipervisor e microcódigo é tratada como rotina crítica, para encurtar ao máximo a janela entre a falha publicada e o patch aplicado.
É uma caixa de areia com paredes dimensionadas para desabamento: dá para construir ali dentro, e o que cair, cai ali dentro. Conforme a competência for demonstrada — par de chaves gerado corretamente, boas práticas seguidas, entendimento comprovado —, o acesso se amplia. Aqui, o caminho importa mais que o destino, e entender o processo importa mais que entregar o resultado. Quem tenta pular etapas do processo de confiança não recebe um atalho: recebe uma cerca.
Como fazer certo
Gere um par de chaves moderno, protegido por passphrase:
ssh-keygen -t ed25519 -a 100 -C "seunome@suamaquina"
O comando cria dois arquivos em ~/.ssh/. O primeiro, id_ed25519, é a chave privada: fica onde está, com permissão 600, protegida pela passphrase que você definiu. Nunca é enviada a ninguém — nem ao provedor, nem ao chefe, nem “só para o suporte dar uma olhada”. O segundo, id_ed25519.pub, é a chave pública: uma única linha de texto começando com ssh-ed25519. É esta, e somente esta, que você envia para cadastro no servidor.
E se a sua chave privada vazar — por e-mail, por captura de tela, por repositório público —, considere-a comprometida para sempre: revogue o cadastro em todos os servidores e gere um novo par.
Conclusão
Segurança da informação não é desconfiança das pessoas; é responsabilidade com todas as pessoas que compartilham a mesma infraestrutura. Nossas portas seguem abertas — inclusive, e principalmente, para quem quer aprender. Mas o acesso à sala de máquinas se conquista com estudo e prática demonstrada, não com autoconfiança.
Quem ainda não sabe o que é uma chave privada, ainda não está pronto para ter uma.