Como Criar Chaves SSH com OpenSSH no macOS ou Linux

A autenticação SSH baseada em chaves é o método padrão da indústria para proteger o acesso remoto a servidores. Em vez de transmitir uma senha pela rede, o seu cliente prova a sua identidade resolvendo um desafio criptográfico que apenas o detentor da chave privada pode responder — o servidor nunca vê a chave privada em si.

Um par de chaves SSH consiste em dois ficheiros matematicamente ligados: uma chave privada (armazenada exclusivamente na sua máquina local, nunca partilhada) e uma chave pública (implementada em cada servidor ao qual precisa de aceder). Quando inicia uma ligação, o OpenSSH utiliza um handshake de desafio-resposta para verificar que a sua chave privada corresponde à chave pública no servidor, concedendo acesso sem pedido de senha.

Por Que as Chaves SSH São Estritamente Superiores à Autenticação por Senha

As senhas são vulneráveis a ataques de força bruta, preenchimento de credenciais, phishing e interceção em redes mal configuradas. As chaves SSH eliminam todos esses vetores de ataque simultaneamente.

• Força criptográfica: Uma chave RSA de 4096 bits ou uma chave Ed25519 é computacionalmente inviável de forçar por força bruta com o hardware atual.
• Nenhum segredo transmitido pela rede: A chave privada nunca sai da sua máquina. O protocolo de autenticação prova a posse sem divulgação.
• Pronto para automação: Pipelines CI/CD, playbooks Ansible, tarefas rsync e backups baseados em cron requerem autenticação não interativa. As chaves SSH tornam isso possível sem incorporar senhas em texto simples em scripts.
• Auditabilidade: Cada par de chaves pode ser identificado de forma única pela sua impressão digital, tornando simples revogar uma única chave comprometida sem rodar credenciais em todo o lado.
• Compatibilidade com ACLs authorized_keys: Pode restringir uma chave pública específica para executar apenas um comando, vinculá-la a um IP de origem ou impedir o encaminhamento de portas — controlos que a autenticação por senha não consegue replicar.

Se estiver a gerir um VPS ou um servidor dedicado, desativar completamente a autenticação por senha e impor o login apenas com chave é uma das medidas de reforço de segurança com maior impacto que pode tomar.

Escolher o Algoritmo de Chave Correto

A documentação original do OpenSSH e a maioria dos tutoriais legados utilizam RSA por padrão. O campo avançou. Aqui está uma comparação precisa de todos os algoritmos que o ssh-keygen suporta atualmente:

Ed25519 é o padrão correto em 2024. Produz chaves mais curtas, assina mais rapidamente e o seu tamanho de chave fixo elimina o risco de gerar acidentalmente uma chave subdimensionada. RSA a 4096 bits continua aceitável para ambientes que precisam de interoperar com sistemas mais antigos anteriores ao suporte Ed25519 (OpenSSH < 6.5, lançado em 2014).

Pré-requisitos

• Uma estação de trabalho macOS ou Linux com OpenSSH instalado. Ambos os sistemas operativos incluem OpenSSH por padrão. Verifique com:

ssh -V

• Acesso de rede a um servidor remoto onde tem uma conta (root ou sem privilégios).
• Familiaridade básica com um terminal.

Em distribuições Linux que incluem uma instalação mínima (Alpine, algumas instalações mínimas Debian), instale as ferramentas de cliente com:

# Debian / Ubuntu
sudo apt install openssh-client

# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install openssh-clients

Passo 1: Abrir um Terminal

macOS: Prima Cmd + Space, escreva Terminal e prima Enter. Em alternativa, navegue até Aplicações > Utilitários > Terminal. Os utilizadores avançados podem usar o iTerm2 ou o terminal integrado no VS Code.

Linux: Prima Ctrl + Alt + T na maioria dos ambientes de trabalho, ou inicie o emulador de terminal da sua distribuição a partir do menu de aplicações.

Passo 2: Gerar o Par de Chaves SSH

Gerar uma Chave Ed25519 (Recomendado)

ssh-keygen -t ed25519 -C "your_email@example.com"

O sinalizador -C acrescenta um comentário legível por humanos à chave pública. Use o seu endereço de email, um nome de host ou uma etiqueta descritiva como "deploy-key-prod" — não tem função criptográfica, mas é inestimável ao auditar ficheiros authorized_keys que acumulam dezenas de entradas.

Gerar uma Chave RSA (Compatibilidade com Sistemas Legados)

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Use -b 4096 explicitamente. O padrão histórico de 2048 bits ainda é tecnicamente aceitável, mas oferece menos margem contra avanços futuros em algoritmos de fatorização. Nunca use -b 1024 ou -b 2048 para novas chaves se 4096 estiver disponível.

Gerar uma Chave Nomeada para um Host Específico

Ao gerir múltiplos servidores ou funções, use ficheiros de chave distintos em vez de reutilizar uma chave em todo o lado. Uma chave comprometida afeta apenas os sistemas onde foi implementada:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod_webserver -C "prod-webserver-2024"

Passo 3: Escolher um Local de Armazenamento

Após executar ssh-keygen, verá:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519):

Prima Enter para aceitar o padrão (~/.ssh/id_ed25519 para Ed25519, ~/.ssh/id_rsa para RSA), ou escreva um caminho personalizado. O local padrão é adequado para uma única chave de uso geral. Para chaves específicas de função, especifique sempre um nome de ficheiro descritivo como mostrado no passo anterior.

Nota crítica sobre permissões de ficheiros: O diretório ~/.ssh/ deve ter o modo 700 e os ficheiros de chave privada devem ter o modo 600. O OpenSSH recusará usar chaves com permissões excessivamente permissivas e apresentará um aviso. Se alguma vez copiar chaves entre máquinas, verifique as permissões imediatamente:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Passo 4: Definir uma Frase-passe

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Uma frase-passe encripta o ficheiro de chave privada em disco usando AES-256-CBC (no OpenSSH moderno). Se um atacante obtiver o seu ficheiro de chave privada — através de um portátil roubado, um backup comprometido ou um snapshot de nuvem mal configurado — uma frase-passe forte é a última linha de defesa que o impede de a utilizar.

Quando ignorar a frase-passe: As contas de serviço automatizadas (pipelines de implementação, agentes de backup) que funcionam sem supervisão precisam legitimamente de chaves sem frase-passe. Nesse caso, restrinja as permissões da chave no lado do servidor usando opções authorized_keys (consulte a secção avançada abaixo) e armazene a chave privada num gestor de segredos em vez de num sistema de ficheiros partilhado.

Após confirmar a frase-passe, o OpenSSH apresenta a impressão digital da chave e uma imagem de arte aleatória:

Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123XYZexampleFingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        .o+.     |
...
+----[SHA256]-----+

Registe a impressão digital. Irá utilizá-la para verificar a identidade da chave ao auditar servidores.

Passo 5: Copiar a Chave Pública para o Servidor Remoto

Método 1: ssh-copy-id (Mais Rápido)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

O sinalizador -i especifica explicitamente qual chave pública copiar, impedindo que ssh-copy-id carregue todas as chaves no seu agente. Ser-lhe-á pedida a senha do servidor uma vez. A ferramenta trata automaticamente da criação de diretórios, adição ao ficheiro e definição de permissões.

Método 2: Implementação Manual (Quando ssh-copy-id Não Está Disponível)

Esta é a abordagem correta quando o sistema remoto é Windows, um dispositivo de rede ou um contentor sem ssh-copy-id no caminho.

Primeiro, apresente a sua chave pública:

cat ~/.ssh/id_ed25519.pub

Copie toda a saída — é uma única linha que começa com ssh-ed25519 (ou ssh-rsa). Em seguida, inicie sessão no servidor e acrescente-a:

ssh user@your-server.com

Uma vez ligado:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-full-public-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Erro comum: Usar > em vez de >> sobrescreve todo o ficheiro authorized_keys, bloqueando todas as outras chaves. Use sempre >> para acrescentar.

Método 3: Redirecionar por SSH num Único Comando

Se já tem acesso por senha e pretende implementar sem iniciar sessão de forma interativa:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Passo 6: Testar a Ligação

ssh -i ~/.ssh/id_ed25519 user@your-server.com

Uma ligação bem-sucedida sem pedido de senha (ou apenas com pedido de frase-passe para a sua chave local) confirma que a configuração está correta. Se a ligação falhar, execute com saída detalhada para diagnosticar:

ssh -vvv -i ~/.ssh/id_ed25519 user@your-server.com

O sinalizador -vvv imprime o registo completo de negociação, mostrando exatamente qual chave foi oferecida, se o servidor a aceitou e onde o handshake falhou.

Passo 7: Configurar ~/.ssh/config para Perfis de Host Persistentes

Escrever o ssh -i ~/.ssh/id_ed25519_prod_webserver user@203.0.113.45 completo de cada vez é propenso a erros e lento. O ficheiro de configuração do cliente SSH elimina isso:

nano ~/.ssh/config

Adicione um bloco de host:

Host prod-web
    HostName 203.0.113.45
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod_webserver
    Port 2222
    ServerAliveInterval 60

Agora ligue-se simplesmente com:

ssh prod-web

Este padrão escala de forma limpa para dezenas de servidores e é essencial para qualquer engenheiro que gere infraestrutura em escala. A diretiva ServerAliveInterval 60 envia um pacote keepalive a cada 60 segundos, impedindo que ligações inativas sejam interrompidas por firewalls — uma frustração comum em fornecedores de nuvem.

Gerir Múltiplas Chaves com o Agente SSH

O agente SSH mantém as chaves privadas desencriptadas em memória durante a sua sessão, para que introduza a frase-passe uma vez em vez de em cada ligação.

Inicie o agente e adicione uma chave:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

No macOS, pode persistir chaves entre reinicializações adicionando o seguinte ao ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

A diretiva UseKeychain yes integra-se com o Keychain do macOS, armazenando a frase-passe de forma segura para que sobreviva a reinicializações do sistema.

Liste todas as chaves atualmente carregadas no agente:

ssh-add -l

Remova uma chave específica do agente:

ssh-add -d ~/.ssh/id_ed25519

Avançado: Restringir Chaves em authorized_keys

O ficheiro authorized_keys suporta opções por chave que reduzem drasticamente o impacto de uma chave comprometida. Estas são colocadas antes do tipo de chave na mesma linha:

command="/usr/bin/rsync --server ...",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... backup-key

Estas opções são particularmente valiosas para chaves de implementação em servidores dedicados onde uma única chave CI/CD comprometida não deve conceder acesso total à shell.

Reforçar o Daemon SSH Após a Implementação de Chaves

Assim que a autenticação baseada em chaves estiver a funcionar, desative completamente a autenticação por senha no servidor. Edite /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Defina as seguintes diretivas:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey

Recarregue o daemon sem desligar a sua sessão atual:

sudo systemctl reload sshd

Não feche a sua sessão SSH existente antes de testar uma nova ligação num terminal separado. Uma configuração incorreta que o bloqueia é recuperável a partir da consola, mas é perturbadora e evitável.

Para servidores que executam ambientes cPanel VPS, esteja ciente de que algumas versões do cPanel gerem a sua própria configuração SSH. Verifique se as alterações ao sshd_config persistem após as atualizações do cPanel verificando /etc/ssh/sshd_config.d/ para ficheiros de substituição.

Rodar e Revogar Chaves SSH

A rotação de chaves é uma prática de higiene de segurança que limita a janela de exposição se uma chave for silenciosamente comprometida. Um calendário de rotação prático é a cada 12 meses para chaves pessoais e a cada 90 dias para chaves de contas de serviço.

Para revogar uma chave: Remova a sua linha do ~/.ssh/authorized_keys em cada servidor onde foi implementada. Não existe um mecanismo central de revogação no OpenSSH padrão — é por isso que manter um inventário de onde cada impressão digital de chave está implementada é importante.

Para rodar uma chave:

1. Gere um novo par de chaves.
2. Implemente a nova chave pública em todos os servidores alvo.
3. Teste a conectividade com a nova chave.
4. Remova a chave pública antiga de todos os ficheiros authorized_keys.
5. Elimine ou arquive a chave privada antiga localmente.

Para ambientes com alojamento VPS em múltiplas regiões, uma ferramenta de gestão de configuração como o Ansible é a solução prática para propagar rotações de chaves em escala.

Transferir Chaves Entre Máquinas

Quando configura uma nova estação de trabalho, precisa de migrar as suas chaves privadas existentes em vez de gerar novas (o que exigiria reimplementar chaves públicas em todo o lado).

Copie a chave privada de forma segura usando scp ou rsync por SSH:

scp ~/.ssh/id_ed25519 newmachine.local:~/.ssh/id_ed25519

Em alternativa, use uma pen USB encriptada ou um gestor de senhas que suporte armazenamento de chaves SSH (1Password, Bitwarden e HashiCorp Vault suportam todos isso). Nunca envie chaves privadas por email nem as armazene em armazenamento em nuvem não encriptado.

Após a transferência, verifique imediatamente as permissões na nova máquina:

chmod 600 ~/.ssh/id_ed25519

Verificar a Impressão Digital da Chave de Host de um Servidor

Na primeira vez que se liga a um servidor, o OpenSSH apresenta a impressão digital da chave de host do servidor e pede-lhe para a confirmar:

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexample.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Nunca escreva yes cegamente. Obtenha a impressão digital esperada através de um canal fora de banda — o painel de controlo do seu fornecedor de alojamento, um colega que aprovisionou o servidor ou a saída da consola do servidor. Este passo previne ataques man-in-the-middle. Para ambientes de alojamento partilhado, a impressão digital esperada está normalmente listada no painel de controlo nas definições de acesso SSH.

Uma vez aceite, a impressão digital é armazenada em ~/.ssh/known_hosts. Se a impressão digital mudar inesperadamente numa ligação subsequente, o OpenSSH recusará a ligação e apresentará um aviso — trate isto como um evento de segurança grave que requer investigação antes de prosseguir.

Matriz de Decisão e Lista de Verificação Técnica

Use esta lista de verificação antes de considerar a sua configuração de chaves SSH pronta para produção:

• [ ] O algoritmo de chave é Ed25519 (ou RSA 4096 para compatibilidade com sistemas legados) — DSA e ECDSA 256 não são aceitáveis para novas implementações
• [ ] As permissões do ficheiro de chave privada são 600; as permissões do diretório ~/.ssh/ são 700
• [ ] Uma frase-passe forte está definida em todas as chaves de utilizador interativas
• [ ] As chaves de conta de serviço sem frases-passe estão restritas através de opções authorized_keys (command=, from=, no-pty)
• [ ] PasswordAuthentication no está definido em /etc/ssh/sshd_config em todos os servidores
• [ ] PermitRootLogin prohibit-password ou PermitRootLogin no está imposto
• [ ] As impressões digitais das chaves de host do servidor foram verificadas fora de banda
• [ ] Existe um inventário de chaves que mapeia cada impressão digital para os servidores onde está implementada
• [ ] O calendário de rotação de chaves está definido e agendado
• [ ] Os blocos de host ~/.ssh/config estão configurados para evitar o uso manual do sinalizador -i
• [ ] O agente SSH é usado para evitar a introdução repetida de frase-passe durante as sessões de trabalho
• [ ] As entradas known_hosts são revistas periodicamente para entradas obsoletas ou inesperadas

FAQ

Qual é a diferença entre chaves SSH Ed25519 e RSA?

O Ed25519 usa criptografia de curva elíptica com uma chave fixa de 256 bits que fornece aproximadamente 128 bits de segurança, assina operações mais rapidamente do que RSA e produz cadeias de chave mais curtas. RSA a 4096 bits fornece segurança comparável, mas é mais lento e gera material de chave maior. Use Ed25519 para todas as novas chaves, a menos que precise de se ligar a um sistema que execute uma versão do OpenSSH anterior à versão 6.5.

Posso usar o mesmo par de chaves SSH para múltiplos servidores?

Sim, tecnicamente. No entanto, a melhor prática é usar pares de chaves distintos por função ou ambiente (acesso pessoal à estação de trabalho, implementação CI/CD, manutenção de base de dados). Isso limita o impacto de uma única chave comprometida e torna a revogação simples sem perturbar sistemas não relacionados.

O que acontece se perder a minha chave privada?

Perde a capacidade de autenticar usando esse par de chaves. A chave pública no servidor torna-se inútil. Deve aceder ao servidor através de um método alternativo — acesso à consola, uma chave secundária ou o acesso de emergência do seu fornecedor de alojamento — e depois remover a chave pública órfã do authorized_keys e implementar um novo par de chaves.

Por que o SSH ainda pede uma senha depois de copiar a minha chave pública?

As causas mais comuns são: permissões incorretas em ~/.ssh/ (deve ser 700) ou ~/.ssh/authorized_keys (deve ser 600) no servidor; o próprio diretório home com permissões de escrita para todos; SELinux ou AppArmor a bloquear o acesso ao diretório .ssh; ou PubkeyAuthentication no estar definido em /etc/ssh/sshd_config. Execute ssh -vvv para identificar exatamente qual método de autenticação está a ser tentado e rejeitado.

Como removo uma chave SSH de um servidor ao qual já não tenho acesso?

Se não tiver outro método de autenticação, contacte a equipa de suporte do seu fornecedor de alojamento ou use o acesso à consola fora de banda (disponível para clientes de VPS e servidor dedicado) para iniciar sessão e editar ~/.ssh/authorized_keys diretamente. É por isso que manter credenciais de acesso à consola separadas das chaves SSH é um requisito operacional inegociável.