Múltiplas chaves SSH sem bagunça: o guia da Sensei pra você nunca mais confundir qual chave abre qual porta
Oi! Aqui é a Sensei da GeHost. Se você mexe com mais de um servidor — seja um projeto pessoal, um freela pra cliente e a sua própria hospedagem — você já deve ter sentido aquele friozinho na barriga: "espera, essa chave é de qual servidor mesmo?". Respira. Vou te mostrar, com calma, como organizar suas chaves SSH pra cada servidor ter a sua própria chave, com nome certo, e você nunca mais errar a porta.
Por que usar uma chave diferente pra cada servidor?
Pensa na chave SSH como uma chave de casa. Você não usaria a mesma cópia de chave pra casa da sua mãe, pro seu apartamento e pro escritório, certo? Cada porta merece a sua chave. Fazendo assim, se um dia você precisar revogar o acesso a um servidor específico (por exemplo, encerrou um projeto), você apaga só aquela chave — sem mexer nas outras.
Passo 1 — Gere uma chave nova para cada servidor
No seu computador, abra o terminal e crie uma chave por vez, dando um nome de arquivo diferente pra cada uma (assim elas não se sobrescrevem). Por exemplo:
- Para o primeiro servidor: rode ssh-keygen -t ed25519 -f ~/.ssh/id_servidor_projeto1 -C "meuemail@exemplo.com - projeto1"
- Para o segundo servidor: rode ssh-keygen -t ed25519 -f ~/.ssh/id_servidor_projeto2 -C "meuemail@exemplo.com - projeto2"
- Quando ele pedir uma passphrase (senha da própria chave), coloque uma. É uma camada extra de segurança caso alguém tenha acesso ao seu computador.
Repare que cada chave gera dois arquivos: um privado (sem sufixo, ex.: id_servidor_projeto1) e um público (com sufixo .pub, ex.: id_servidor_projeto1.pub). A privada é sagrada — nunca envie ela pra ninguém, nem cole em chat, nem suba pra nuvem sem criptografia. A pública é a que você entrega ao servidor.
Passo 2 — Dê nomes que contam a história
O maior motivo de confusão é chamar tudo de "id_rsa". Em vez disso, use um nome que já explica pra que serve, tipo id_ed25519_projeto1, id_ed25519_clientex ou id_ed25519_gehost_meudominio. Você agradece a si mesmo daqui a seis meses.
Passo 3 — Autorize a chave pública no servidor certo
Agora é hora de "entregar a cópia da chave" pro servidor que ela pertence. Se o seu plano tiver acesso SSH liberado, normalmente isso é feito dentro do cPanel, na seção de Segurança > Acesso SSH / Gerenciador de Chaves SSH, onde você pode importar a chave pública (o conteúdo do arquivo .pub) e autorizá-la. Se preferir usar o terminal, o comando ssh-copy-id -i ~/.ssh/id_servidor_projeto1.pub seuusuario@seudominio.com também faz esse trabalho.
Dica da Sensei: sempre confira, antes de copiar, se você está apontando o arquivo .pub (público) e não o privado. É um erro comum — e um só é seguro, o outro não.
Não tem certeza se o seu plano possui acesso SSH liberado, ou qual é o caminho exato no seu painel? Fale com o suporte da GeHost pelo painel.gehost.com.br que a gente te orienta certinho.
Passo 4 — Crie um "mapa" com o arquivo de configuração do SSH
Esse é o truque que resolve 90% da confusão: um arquivo chamado config dentro da pasta ~/.ssh/ no seu computador, onde você cria um "apelido" pra cada servidor. Assim, em vez de decorar qual chave usar em qual comando, você só digita o apelido. Um exemplo de como ficaria o conteúdo desse arquivo:
- Host projeto1 — em seguida as linhas HostName seudominio1.com, User seuusuario e IdentityFile ~/.ssh/id_servidor_projeto1
- Host clientex — em seguida HostName dominiodocliente.com, User usuariodele e IdentityFile ~/.ssh/id_servidor_projeto2
Com isso configurado, conectar fica tão simples quanto digitar ssh projeto1 ou ssh clientex no terminal. O sistema já sabe sozinho qual chave, qual usuário e qual endereço usar — zero chance de confundir.
Passo 5 — Teste antes de confiar de olhos fechados
Depois de configurar, sempre teste a conexão pelo apelido que você criou (ex.: ssh projeto1) antes de sair usando em rotinas automáticas, scripts de deploy ou backups. Se conectar de primeira sem pedir senha do usuário (só a passphrase da chave, se você colocou uma), está tudo certo.
Boas práticas pra nunca mais se perder
- Uma chave por servidor/projeto, sempre. Nunca reaproveite a mesma chave em ambientes diferentes.
- Use passphrase nas chaves privadas — é uma senha extra caso seu computador seja comprometido.
- Guarde uma cópia de backup das chaves privadas em um lugar seguro (um gerenciador de senhas, por exemplo), fora do computador principal.
- Revogue o que não usa mais. Encerrou um projeto ou trocou de equipe? Remova a chave pública correspondente do servidor.
- Nunca envie a chave privada por e-mail, chat ou WhatsApp. Só a pública pode circular.
Ficou com alguma dúvida?
Sem problema — configurar chaves SSH pode parecer chinês no começo, mas depois vira rotina. Se travar em algum passo, é só chamar o suporte da GeHost pelo painel.gehost.com.br que a gente te ajuda a destrinchar isso com calma. Você não está sozinho nessa. 🌱