Se você administra servidor, mexe com deploy ou só precisa acessar uma máquina remota, provavelmente já usou SSH. Só que muita gente ainda depende de senha, e isso funciona… porém cria um ponto fraco óbvio quando a porta fica exposta.

As chaves SSH entram justamente aí. Elas permitem autenticação por chave pública, ou seja, você prova que é você sem mandar senha pela rede. Além disso, elas são a base de várias automações modernas: backups, rotinas de manutenção, CI/CD, cópia de arquivos e integração com Git.

Neste artigo, você vai entender como funcionam as chaves SSH do começo ao fim: quais tipos existem, o que acontece na conexão, como gerar e instalar, e também como manter tudo organizado e seguro.

O que é SSH e onde as chaves entram

SSH significa Secure Shell (muita gente fala “Secure Socket Shell”, porém o nome certo é Secure Shell). Na prática, é um protocolo que cria um canal criptografado entre um cliente (seu computador) e um servidor (a máquina remota). Assim, dá para executar comandos, copiar arquivos e administrar sistemas com mais segurança.

O “pulo do gato” é a autenticação. Você precisa provar ao servidor que tem permissão para entrar. Isso pode ser feito com senha, mas também pode ser feito com chaves SSH. E é aí que muita coisa melhora: menos senha circulando, menos tentativa automática de login, e mais controle quando o processo é bem configurado.

Como funcionam as chaves SSH na prática

Para entender como funcionam as chaves SSH, pense nelas como um par: uma parte fica “pública” e a outra fica “privada”. Elas trabalham juntas, porém não são a mesma coisa e não têm o mesmo papel.

Par de chaves: pública e privada

  • Chave privada: fica com você. É o “segredo” que prova sua identidade. Não deve ser enviada para servidor, não deve ir para repositório, e não deve ser compartilhada.
  • Chave pública: pode ser compartilhada. Ela é cadastrada no servidor, dizendo: “se alguém provar que tem a privada correspondente, pode entrar”.

Quando você tenta se conectar, o servidor usa a chave pública cadastrada para validar se você realmente possui a chave privada. Em outras palavras, você não manda sua chave privada para o servidor; você usa a privada localmente para responder a um desafio criptográfico, e o servidor confirma usando a pública.

O que acontece na conexão

Em uma conexão SSH típica, o fluxo é mais ou menos assim:

  • Primeiro, cliente e servidor negociam os algoritmos (criptografia, troca de chaves, MAC etc.).
  • Depois, o cliente valida o host (o servidor) para evitar golpe do tipo man-in-the-middle.
  • Logo em seguida, o servidor pede autenticação do usuário (senha ou chave pública).
  • Por fim, a sessão é estabelecida e o tráfego passa criptografado.

Esse segundo passo é importante e às vezes passa batido: o SSH também autentica o servidor. Por isso existe o arquivo known_hosts no seu computador. Na primeira conexão, você vê aquela mensagem pedindo confirmação da “fingerprint” do host. Depois, nas próximas conexões, o SSH lembra a chave do host e alerta se algo mudar de forma suspeita.

Chaves de sessão: a criptografia do tráfego

Mesmo quando você usa chave pública para login, a criptografia do tráfego do dia a dia normalmente usa chave simétrica (mais rápida). Então, durante o “aperto de mão” inicial, o SSH cria uma chave de sessão temporária e usa isso para criptografar os dados enquanto a conexão estiver ativa.

Ou seja: chaves SSH (pública/privada) ajudam na autenticação, e a chave de sessão cuida da proteção do tráfego.

Tipos de chaves SSH: usuário, host e sessão

No uso prático, você vai ouvir falar de “tipos” de chaves por função. Isso ajuda porque não é só “uma chave” e pronto.

Chaves de usuário (authorized keys e identity keys)

Quando falamos em acesso de pessoas e automações, entram duas peças:

  • Chave pública autorizada (no servidor): fica no arquivo ~/.ssh/authorized_keys do usuário. Ela define “quem pode entrar”.
  • Chave privada de identidade (no cliente): fica com o usuário/serviço que vai se conectar.

Assim, o servidor mantém uma lista de chaves públicas autorizadas, e o cliente usa a privada correspondente para se autenticar.

Chaves de host

As chaves de host identificam o servidor. Elas existem para impedir que você se conecte a um servidor falso sem perceber. Essa ideia é tratada como parte essencial do SSH e, inclusive, aparece como ponto de atenção em guias de gestão e segurança do protocolo. :contentReference[oaicite:0]{index=0}

Chaves de sessão

As chaves de sessão são temporárias e negociadas na hora. Elas criptografam os dados da conexão enquanto ela estiver ativa. Depois, a sessão acaba e essas chaves deixam de ter utilidade.

Por que a chave SSH é importante

Chaves SSH viraram padrão por dois motivos: segurança e automação. Além disso, elas reduzem atrito: menos senha digitada, menos senha armazenada, e mais previsibilidade em processos.

Segurança: menos senha circulando

Com senha, você tem dois problemas comuns: reutilização e força bruta. Com chave pública, você tira a senha do caminho e, dessa forma, corta uma boa parte desse risco.

Isso não significa “risco zero”. Se a chave privada vazar, alguém pode entrar como você. Então, a segurança depende muito de boas práticas de armazenamento, passphrase e inventário.

Automação: o “motor” de muita rotina de TI

Em servidores e nuvem, automação é rotina: backup, atualização, deploy, coleta de logs, sincronização de arquivos. É aí que as chaves SSH aparecem porque permitem conexões sem intervenção humana, desde que tudo esteja bem controlado.

Quando dá errado: dois casos que viraram alerta

GoDaddy (2019/2020): a empresa informou que uma violação iniciada em outubro de 2019 foi descoberta em abril de 2020 e afetou credenciais de SSH de cerca de 28 mil clientes. Eles resetaram os logins SSH e notificaram os usuários. :contentReference[oaicite:1]{index=1}

GitHub e chaves fracas (2021): em outubro de 2021, o GitHub revogou chaves SSH geradas por versões vulneráveis do GitKraken (e outras possivelmente afetadas) após um aviso ligado a uma falha que podia gerar chaves fracas/duplicadas. Eles também bloquearam o uso dessas chaves para reduzir risco. :contentReference[oaicite:2]{index=2}

Esses exemplos ajudam porque mostram um ponto simples: SSH é seguro, porém o gerenciamento das credenciais é o que define o resultado final.

Como criar uma chave SSH (Linux, macOS e Windows)

Agora vamos para o lado prático. A ideia é sempre a mesma: gerar o par de chaves, guardar a privada com cuidado, e cadastrar a pública no servidor.

1) Gerando a chave com ssh-keygen (Linux/macOS/Windows)

Em Linux e macOS, normalmente você já tem OpenSSH instalado. No Windows 10/11, também é comum ter o cliente OpenSSH disponível, ou então você pode usar Git Bash/WSL. Depois, rode:

ssh-keygen -t ed25519 -a 64 -C "[email protected]"

Se você precisa de compatibilidade com sistemas antigos, pode usar RSA com tamanho forte:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Durante a geração, o sistema vai perguntar onde salvar e vai oferecer a opção de passphrase. Use passphrase, inclusive em chaves para trabalho. Isso adiciona uma camada caso o arquivo da privada seja copiado.

No final, você terá algo como:

  • ~/.ssh/id_ed25519 (privada)
  • ~/.ssh/id_ed25519.pub (pública)

2) Instalando a chave pública no servidor

A forma mais simples (quando disponível) é:

ssh-copy-id usuario@ip-ou-dominio

Se você não tem ssh-copy-id, dá para fazer manualmente:

  • Copie o conteúdo do arquivo .pub
  • No servidor, cole dentro de ~/.ssh/authorized_keys

Um exemplo (manual) no servidor:

mkdir -p ~/.ssh chmod 700 ~/.ssh nano ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

Essas permissões importam. Se o ~/.ssh ou o authorized_keys estiverem “abertos demais”, o SSH pode ignorar as chaves por segurança.

3) Testando o login com chave

ssh usuario@ip-ou-dominio

Se tudo estiver certo, você entra sem digitar a senha do servidor (ou só digita a passphrase da chave, se configurou uma).

4) Usando a chave com Git

Para GitHub/GitLab e afins, o processo é parecido: você adiciona a chave pública na plataforma. Depois, testa:

ssh -T [email protected]

Em seguida, clone usando SSH:

git clone [email protected]:usuario/repositorio.git

Boas práticas para proteger e gerenciar chaves SSH

A parte “difícil” não é gerar uma chave. O difícil é manter isso sob controle com o tempo, principalmente em equipe, com servidores diferentes, automações e troca de pessoas.

Use passphrase e, quando fizer sentido, ssh-agent

Passphrase protege o arquivo da chave privada. Além disso, para não digitar a passphrase toda hora, você pode usar ssh-agent. Assim, você destrava a chave uma vez e o agente mantém a autorização em memória por um período.

Por outro lado, evite sair encaminhando agent (agent forwarding) sem entender o risco: se você encaminha seu agente para uma máquina que não controla bem, alguém pode tentar usar o agente para acessar outros destinos.

Não compartilhe a mesma chave entre pessoas

Uma regra simples: uma pessoa, uma chave (e idealmente uma chave por finalidade). Chave compartilhada vira “terra de ninguém”: se algo acontecer, você perde rastreio de quem usou.

Essa ideia aparece direto em orientações de gestão de chaves e também em discussões de boas práticas de SSH em ambientes corporativos. :contentReference[oaicite:3]{index=3}

Tenha inventário e processo de entrada/saída

Chave SSH é credencial. Então, precisa de ciclo de vida: provisionar, revisar, revogar.

O problema é que muitas empresas não fazem isso bem. Em um estudo citado por empresas de segurança, 90% disseram não ter um inventário completo e preciso de todas as chaves SSH, o que dificulta saber se há chaves que não deveriam existir. :contentReference[oaicite:4]{index=4}

Além disso, pesquisas e matérias técnicas já relacionaram falhas no controle de SSH com risco real de ataque em nível de root, justamente por causa de chaves espalhadas e sem controle. :contentReference[oaicite:5]{index=5}

Rotacione e revogue com frequência razoável

Chaves SSH não “expiram” automaticamente por padrão. Então, é você (ou sua política interna) que define quando trocar. Em ambientes simples, dá para trocar manualmente; porém, em ambientes grandes, a rotação manual vira confusão, porque é fácil quebrar acessos legítimos ou esquecer algum servidor.

Se você tem muitos servidores, considere automatizar a rotação e a publicação de chaves, justamente para reduzir erro humano e manter rastreio.

Não deixe chaves embutidas em código e scripts

Evite colocar chaves privadas dentro de:

  • repositórios Git
  • imagens Docker
  • scripts distribuídos
  • aplicações com “config” versionado

Se a automação precisa de acesso, prefira usar mecanismos próprios de gestão de segredos e identidades do seu ambiente. Em outras palavras: chave privada não é “config normal”.

Registre e audite acessos privilegiados

Em servidores críticos, é importante ter log e trilha: quem entrou, quando, de onde e o que fez. Isso pode ser feito com logs do SSH, centralização de logs e, em alguns casos, ferramentas de gestão de acesso privilegiado. O objetivo aqui é simples: se acontecer algo, você consegue investigar sem depender de adivinhação.

Algoritmos: ed25519, RSA e o que evitar

Na hora de gerar a chave, o algoritmo importa. E aqui vale manter o básico bem feito.

  • ed25519: ótima opção na maioria dos cenários modernos (segura e rápida). Além disso, costuma ser o padrão recomendado quando o ecossistema é atual.
  • RSA: ainda é comum e compatível. Porém, prefira tamanhos fortes (3072 ou 4096). E em ambientes modernos, garanta que está usando assinaturas RSA com SHA-2 quando necessário.
  • DSA (ssh-dss): evite. O OpenSSH desabilitou por padrão esse tipo a partir da versão 7.0 por ser fraco. :contentReference[oaicite:6]{index=6}
  • ECDSA: pode ser aceitável em muitos ambientes, porém algumas organizações preferem padronizar em ed25519 por simplicidade e por políticas internas.

Se você já tem infraestrutura antiga, o ponto é: planeje migração. Assim, você não fica preso em algoritmo legado só porque “sempre foi assim”.

Checklist rápido: configuração segura sem complicar

  • Gerar chave com ed25519 (ou RSA 4096 se precisar de compatibilidade).
  • Usar passphrase na chave privada.
  • Guardar a chave privada apenas no dispositivo certo (e com backup seguro).
  • Cadastrar a chave pública em authorized_keys com permissões corretas.
  • Evitar chaves compartilhadas entre pessoas.
  • Ter inventário: quais chaves existem e onde estão autorizadas.
  • Revogar chaves de quem saiu do time imediatamente.
  • Rotacionar chaves periodicamente (manual em pequeno, automatizado em grande).
  • Conferir “primeira conexão” e alertas do known_hosts com atenção.

Conclusão

Entender como funcionam as chaves SSH é mais do que decorar comandos. É saber que existe um par (pública/privada), que o host também precisa ser verificado, e que o tráfego usa chaves de sessão. Depois, vem a parte que mais pesa no mundo real: inventário, revogação e boas práticas, porque a maior parte dos incidentes nasce de chaves espalhadas e sem controle. :contentReference[oaicite:7]{index=7}

Se você quiser, eu posso adaptar este guia para o seu cenário (por exemplo: “SSH em VPS”, “SSH em empresa com time”, “SSH para deploy com GitHub Actions”), incluindo um passo a passo enxuto e um modelo de política de chaves para você copiar e usar.


O Futuro do seu Site Começa com um Teste Grátis!

Na Hostbung, seu projeto encontra tudo o que precisa para crescer e permanecer online, 24 horas por dia. Mais do que uma provedora de hospedagem de sites com infraestrutura de ponta, somos uma parceira em todas as etapas da sua jornada digital.
Acreditamos em facilitar sua vida e em construir uma comunidade que realmente faz a diferença. Queremos que você faça parte disso! Por isso, estamos oferecendo uma Hospedagem de site com 30 dias grátis, ou Revenda de hospedagem com 30 dias grátis para você conhecer nosso serviço sem nenhum compromisso.