Chaves SSH explicadas
A autenticação por chave SSH é a maneira de entrar em um servidor sem senha: em vez de digitar um segredo que o servidor possa verificar, seu computador prova que detém uma chave privada assinando um desafio que o servidor envia, e o servidor verifica a assinatura com a chave pública que já tem arquivada. A chave privada nunca cruza a rede, então não há nada para interceptar, nada para pescar com phishing e nada para adivinhar. Este artigo explica como funcionam as duas metades de um par de chaves, qual tipo de chave escolher em 2026, como as impressões digitais impedem um intermediário na sua primeira conexão, como manter authorized_keys e known_hosts limpos, e exatamente o que fazer quando uma chave vaza. Para gerar, inspecionar ou converter uma chave no navegador, use o Conjunto de chaves SSH, e para verificar as senhas que você ainda usa, a Verificação de vazamento de senha.
O que é autenticação por chave SSH
Cada login é uma pergunta que o servidor faz — você é quem diz ser? — e uma senha a responde entregando o próprio segredo. Essa é a fraqueza de todo o arranjo: o segredo viaja, pode ser ouvido, pode ser reproduzido e pode ser adivinhado, tentativa após tentativa, até cair. A autenticação por chave SSH muda a resposta. Em vez de enviar o segredo, seu computador assina um desafio aleatório do servidor com uma chave privada que nunca sai da sua máquina, e o servidor verifica a assinatura com a chave pública guardada no seu arquivo authorized_keys. A prova é nova a cada vez, porque o desafio é aleatório; o segredo nunca aparece no fio, então um ouvinte não aprende nada que possa reutilizar, e não há senha para adivinhar, porque nenhuma senha está envolvida.
A ideia é mais antiga que a internet moderna — a criptografia de chave pública data dos anos 1970 — mas o SSH a tornou a maneira cotidiana de alcançar um servidor, e o protocolo a carrega desde então. Quando você executa ssh usuario@servidor, o cliente e o servidor combinam uma sessão, o servidor apresenta um desafio vinculado à sua conta, e seu agente SSH o assina com a chave privada, geralmente depois que você desbloqueia a chave uma vez com uma senha. Se a assinatura for verificada, você entra. Nada na troca depende de um segredo compartilhado que o servidor também conheça, e é por isso que uma violação do servidor não expõe suas credenciais: o servidor detém apenas chaves públicas, e uma chave pública é inútil para entrar. Essa assimetria — o servidor pode verificar, mas não pode se passar por você — é todo o argumento de segurança das chaves, e também é a razão pela qual perder o controle da metade privada é a única falha que importa.
A chave pública e a chave privada
Um par de chaves são duas metades com regras opostas, e a maioria dos erros de SSH vem de tratá-las da mesma forma. A chave pública é feita para ser copiada em toda parte: cole-a em authorized_keys de cada servidor que você usa, na sua conta de hospedagem Git, em qualquer serviço que aceite chaves SSH. Ela pode ser publicada em um repositório público, impressa em um slide ou enviada por e-mail a um administrador, porque tudo o que ela permite a qualquer pessoa é verificar uma assinatura. Conhecer sua chave pública não dá a um invasor nada para entrar, da mesma forma que conhecer o número da sua casa não dá a ninguém a chave da sua porta. A metade pública é uma fechadura, não uma chave, e fechaduras são feitas para serem vistas.
A chave privada é a própria chave, e sua regra é exatamente o oposto: ela nunca sai da sua máquina, só você pode lê-la, e nunca deve ser colada em um chat, um ticket, um e-mail, uma postagem em fórum ou um documento compartilhado — nem para perguntar se ela é segura. Quem a tiver pode entrar como você em cada servidor que confia na chave pública correspondente, sem prompt de senha e sem segundo fator no caminho, a menos que você tenha configurado um. No disco ela mora em ~/.ssh, protegida por permissões de arquivo — chmod 600, leitura e escrita apenas do proprietário — e, idealmente, por uma senha, que criptografa o arquivo para que uma cópia roubada continue inútil sem as palavras que a desbloqueiam. A senha não faz parte da chave; é um cadeado na caixa onde a chave está. Perca a caixa e o cadeado é a única coisa entre o ladrão e seus servidores, e é por isso que uma chave privada sem senha nunca deve sair de uma máquina que você controla totalmente.
Ed25519 vs ECDSA vs RSA: qual escolher em 2026
Em 2026, a resposta padrão é Ed25519, e é o padrão que este site gera. Ed25519 é uma chave de curva elíptica de 256 bits: gera-se em uma fração de segundo, assina rapidamente e produz uma chave pública que cabe em uma única linha curta. É suportada pelo OpenSSH desde 2014 e por todos os servidores e clientes atuais, e sua segurança repousa em uma curva projetada abertamente, sem constantes suspeitas. Não há razão prática para escolher outra coisa para uma chave nova, a menos que algo no seu ambiente force sua mão. Se você levar uma recomendação deste artigo, que seja esta: gere Ed25519, defina uma senha e siga em frente.
Os outros tipos existem para as exceções. ECDSA nas curvas NIST P-256 ou P-384 é a escolha certa onde a política exige curvas NIST — alguns ambientes regulamentados e tokens de hardware antigos as especificam — e é um bom recurso se um navegador ou dispositivo não puder gerar Ed25519. RSA continua sendo o recurso universal: RSA 2048 é o mínimo que vale usar, RSA 3072 ou 4096 a escolha quando o outro lado não pode usar curvas elípticas, o que hoje significa principalmente sistemas muito antigos e alguns dispositivos embarcados. Qualquer coisa abaixo de RSA 2048 — RSA 1024, DSA, ssh-dss — é legado e deve ser aposentada: o Conjunto de chaves SSH a marca como fraca exatamente por essa razão. O tamanho da chave não é tudo, porém: uma chave RSA de 4096 bits copiada para um laptop que você já não possui é pior que uma chave Ed25519 de 256 bits bem guardada, porque o modo de falha das chaves SSH quase nunca é a matemática. É o arquivo.
Impressões digitais e a primeira conexão
Na primeira vez que você se conecta a um servidor, o SSH mostra algo que parece uma sequência aleatória de caracteres e pergunta se você confia nela: 256 SHA256:M8zvXkwyrGfPUmaHSSdA1aFQkH8AVSRycOxaZHru7dQ. Essa sequência é a impressão digital da chave de host do servidor — um hash da chave pública do servidor — e é a única coisa entre você e um intermediário. Se a impressão corresponder à publicada pelo seu administrador, ou à que você verificou por um canal separado, então a máquina que responde é realmente o servidor que você pretendia alcançar. Se não corresponder, pare: alguém pode estar interceptando a conexão, ou o servidor pode ter sido reconstruído com uma chave nova, e de qualquer forma o movimento seguro é verificar antes de digitar yes. Esse prompt é o SSH fazendo seu trabalho mais importante, e as pessoas que se metem em problemas são as que se treinam a digitar yes sem lê-lo.
Você pode verificar uma impressão digital antes mesmo de se conectar, com ssh-keygen -lf, que imprime uma linha por chave: o tamanho em bits, a impressão digital, o comentário e o tipo de chave entre colchetes, por exemplo 256 SHA256:… [email protected] (ED25519). O Conjunto de chaves SSH imprime impressões digitais exatamente neste formato, para que um valor que você vê no navegador possa ser comparado caractere por caractere com o que o servidor mostra. Depois que você aceita uma chave de host, o SSH a salva em ~/.ssh/known_hosts e avisa em voz alta — recusando-se a conectar — se ela mudar. Esse aviso não é um incômodo a contornar com uma flag; é o alarme disparando. A única exceção rotineira é um servidor legitimamente reconstruído, caso em que o administrador deveria ter publicado a nova impressão com antecedência, e você remove a entrada antiga com ssh-keygen -R nome-do-host antes de reconectar.
Higiene de authorized_keys e known_hosts
Cada linha no arquivo authorized_keys de um servidor é uma porta, e as portas continuam abertas muito depois que a pessoa que precisava delas já foi embora. O laptop de um prestador de serviços, um trabalho de integração contínua, uma chave gerada em uma máquina que já foi apagada, um colega que mudou de equipe há dois anos — cada uma é uma linha que ainda funciona, e cada uma é uma credencial que você já não vigia. A auditoria é simples e vale a pena a cada poucos meses: copie o arquivo, cole-o na aba Inspecionar do Conjunto de chaves SSH e veja o que volta. Duplicatas — a mesma chave pública duas vezes — significam que alguém colou uma chave novamente em vez de verificar, e devem ser reduzidas a uma linha. Entradas fracas — RSA abaixo de 2048, DSA, ssh-dss — devem ser removidas e substituídas. E qualquer linha cujo comentário nomeie uma pessoa, uma máquina ou um propósito que você já não reconhece deve ser tratada como uma porta a fechar até que seu dono possa reivindicá-la.
known_hosts merece a mesma atenção do outro lado. Ele registra a chave de host de cada servidor ao qual você se conectou, e o SSH verifica cada nova conexão com ele. Algumas entradas têm hash — |1| seguido de base64 — o que oculta o nome do host, um recurso de privacidade para laptops que podem ser perdidos ou inspecionados; o Conjunto de chaves SSH relata essas entradas como com hash em vez de fingir que são legíveis, porque uma entrada com hash não pode ser verificada com uma impressão publicada, apenas confiada como já aceita. O próprio arquivo também é evidência: um known_hosts cheio de servidores que você já não usa é um mapa de onde suas credenciais estiveram, e podá-lo não custa nada. Juntos, os dois arquivos são o registro completo da sua confiança SSH nas duas direções — quem pode entrar como você, e em quais máquinas você confia para serem elas mesmas — e ambos apodrecem em silêncio se ninguém olhar.
Quando uma chave vaza — e a nota sobre a senha
Uma chave vazada não é um mistério a investigar primeiro e sobre o qual agir depois; é uma chave a substituir, e a ordem das operações é curta. Gere um novo par de chaves. Remova a chave pública antiga de authorized_keys em cada servidor e cada serviço — seus servidores, sua hospedagem Git, seus pipelines de implantação, qualquer lugar onde a chave foi instalada. Depois verifique o que a chave antiga podia alcançar e procure qualquer coisa fora do lugar: novas linhas em authorized_keys que você não adicionou, logins em horas em que você não estava trabalhando, processos desconhecidos. Se encontrar algo, trate como uma violação, não como um susto, e investigue a partir daí. O que você não deve fazer é excluir a chave privada antiga do seu laptop e considerar o trabalho feito: excluir sua cópia não faz nada com as cópias que vazaram, e a chave pública ainda em authorized_keys continua sendo uma porta que funciona.
Uma senha não muda esta lista, mas muda a urgência com que você a executa. Uma chave protegida por senha que vaza como arquivo continua sendo um problema — um invasor pode tentar adivinhar a senha offline, à velocidade da máquina — mas uma senha forte compra o tempo para girar antes que a adivinhação tenha sucesso. Uma chave sem criptografia não compra tempo algum, e é por isso que este site é franco sobre o que seu gerador produz: a versão 1 gera chaves sem criptografia, sem opção de senha, porque o KDF bcrypt do OpenSSH para chaves privadas criptografadas é escopo da versão 2. Se você gerar uma chave aqui, proteja o arquivo com chmod 600 e adicione uma senha na sua própria máquina com ssh-keygen -p — leva dez segundos, converte o arquivo no lugar, e é o hábito de maior valor de todo este artigo. Gere a chave, defina a senha, instale apenas a metade pública, audite os arquivos duas vezes por ano e verifique cada impressão digital antes de confiar nela: essa é toda a disciplina, e cabe em um cartão.