Como Fazer Upload de uma Chave Pública SSH para um VPS Existente

Uma chave pública SSH é uma credencial criptográfica armazenada em ~/.ssh/authorized_keys num servidor remoto que concede acesso a qualquer cliente que possua a chave privada correspondente — sem transmitir uma palavra-passe pela rede. Carregar a sua chave pública para um VPS existente substitui ou complementa a autenticação baseada em palavra-passe com criptografia assimétrica, eliminando a superfície de ataque explorada por campanhas de força bruta e preenchimento de credenciais.

Este guia abrange todas as etapas do processo: geração de chaves, métodos de carregamento manual e automatizado, reforço de permissões, ajuste de sshd_config, gestão de múltiplas chaves e modos de falha comuns que afetam até administradores experientes.

Por Que a Autenticação por Chave SSH Supera as Palavras-passe

Antes de executar um único comando, vale a pena compreender a mecânica criptográfica. Quando se autentica com um par de chaves, o servidor emite um desafio encriptado com a sua chave pública. Apenas o detentor da chave privada correspondente pode desencriptar e assinar a resposta. Nenhum segredo é transmitido — contraste isto com a autenticação por palavra-passe, onde a própria credencial viaja pela rede (mesmo que encapsulada em TLS).

A conclusão prática: em qualquer ambiente de VPS Hosting exposto à internet pública, as chaves SSH não são um reforço opcional — são a linha de base.

Pré-requisitos

• Um VPS existente acessível via SSH (login por palavra-passe ou chave existente funciona atualmente)
• Uma máquina local com Linux, macOS ou Windows com OpenSSH ou PuTTY
• Privilégios suficientes no VPS para escrever no diretório home do utilizador alvo
• Familiaridade básica com um terminal e um editor de texto como nano ou vim

Passo 1: Gerar um Par de Chaves SSH

Se já possui um par de chaves em ~/.ssh/id_ed25519 ou ~/.ssh/id_rsa, avance. Caso contrário, gere um agora.

Escolher o Algoritmo Correto

Ed25519 é o padrão moderno. Use RSA 4096 apenas ao ligar a servidores legados que não suportam Ed25519.

Gerar um par de chaves Ed25519:

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

Gerar um par de chaves RSA 4096 (sistemas legados):

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

Durante a geração da chave, será solicitado um caminho de gravação e uma frase-passe opcional. Aceitar o caminho predefinido (~/.ssh/id_ed25519) é adequado para a maioria dos utilizadores. Defina sempre uma frase-passe — ela encripta a chave privada no disco usando AES-256, de modo que um portátil roubado não significa automaticamente um servidor comprometido.

O processo produz dois ficheiros:

~/.ssh/id_ed25519 — a sua chave privada. Nunca a partilhe, nunca a copie para um servidor, nunca a submeta a um sistema de controlo de versões.
~/.ssh/id_ed25519.pub — a sua chave pública. É seguro distribuí-la livremente.

Exiba a chave pública para poder copiá-la:
cat ~/.ssh/id_ed25519.pub
O resultado será semelhante a:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com
Copie toda a cadeia de uma única linha, incluindo o prefixo do algoritmo e o comentário no final.
Passo 2: Iniciar Sessão no Seu VPS
Ligue-se ao VPS usando o seu método de autenticação atual:
ssh root@your_vps_ip
Substitua your_vps_ip pelo endereço IPv4 ou IPv6 real do seu servidor. Se estiver a gerir uma conta de utilizador não-root, substitua root pelo nome de utilizador apropriado. Em Servidores Dedicados onde pode ter múltiplas contas de utilizador, prefira sempre implementar chaves para um utilizador não-root e use sudo para escalada de privilégios.
Passo 3: Preparar o Diretório .ssh
Após iniciar sessão, verifique ou crie o diretório .ssh para o utilizador alvo:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
A permissão 700 (rwx------) é obrigatória. O OpenSSH recusará silenciosamente o uso de authorized_keys se o diretório .ssh tiver permissões de escrita para o grupo ou para todos. Esta é uma das razões mais comuns pelas quais a autenticação por chave falha após uma configuração aparentemente correta.
Passo 4: Adicionar a Chave Pública a authorized_keys
Método A: Colagem Manual (Universal)
Abra ou crie o ficheiro authorized_keys:
nano ~/.ssh/authorized_keys
Cole a sua chave pública numa nova linha. Cada linha neste ficheiro representa uma chave autorizada. Guarde com Ctrl+X, depois Y, depois Enter.
Defina as permissões corretas:
chmod 600 ~/.ssh/authorized_keys
A permissão 600 (rw-------) garante que apenas o proprietário do ficheiro pode lê-lo ou escrevê-lo. O OpenSSH aplica isto de forma rigorosa.
Método B: ssh-copy-id (Recomendado pela Rapidez)
Se a sua máquina local tiver ssh-copy-id disponível (padrão no Linux e macOS), este único comando trata automaticamente da criação do diretório, adição da chave e definição das permissões:
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip
Ser-lhe-á solicitada a palavra-passe SSH atual uma vez. Após isso, o login baseado em chave estará ativo. O sinalizador -i especifica explicitamente qual chave pública carregar, evitando carregamentos acidentais da chave errada.
Método C: Linha Única via cat e Pipe (Automatizável)
Útil em pipelines de automação ou quando ssh-copy-id não está disponível:
cat ~/.ssh/id_ed25519.pub | ssh root@your_vps_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Esta abordagem é segura em termos de idempotência no sentido em que acrescenta em vez de sobrescrever, preservando quaisquer chaves autorizadas existentes.
Passo 5: Verificar a Propriedade Correta dos Ficheiros
Um problema frequentemente ignorado: se criou o diretório .ssh ou o ficheiro authorized_keys como root ao configurar a conta de outro utilizador, a propriedade estará errada e o SSH rejeitará a chave silenciosamente.
Verifique a propriedade:
ls -la ~/.ssh/
O resultado deve mostrar o nome de utilizador alvo como proprietário e grupo tanto para o diretório como para o ficheiro:
drwx------ 2 alice alice 4096 Jan 15 10:00 .ssh
-rw------- 1 alice alice  571 Jan 15 10:00 .ssh/authorized_keys
Se a propriedade estiver incorreta, corrija-a (execute como root):
chown -R alice:alice /home/alice/.ssh
Passo 6: Testar o Login por Chave SSH
Termine a sessão atual:
exit
Reconecte-se especificando explicitamente a chave para confirmar a configuração:
ssh -i ~/.ssh/id_ed25519 root@your_vps_ip
Se o login for bem-sucedido sem solicitar uma palavra-passe (ou solicitar apenas a frase-passe da chave local), a configuração está correta. Se ainda pedir a palavra-passe do servidor, avance para a secção de resolução de problemas abaixo.
Passo 7: Reforçar a Configuração do Daemon SSH
Assim que o login baseado em chave estiver confirmado a funcionar, desative a autenticação por palavra-passe para eliminar completamente o vetor de ataque de força bruta por palavra-passe.
Abra o ficheiro de configuração do daemon SSH:
nano /etc/ssh/sshd_config
Localize e defina as seguintes diretivas. Se uma linha estiver comentada com #, remova o # e defina o valor:
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes
Uma nota sobre PermitRootLogin prohibit-password: esta definição permite o login root exclusivamente via chave, bloqueando o acesso root por palavra-passe enquanto ainda permite sessões root autenticadas por chave. Para o máximo reforço, defina como no e use um utilizador não-root com sudo.
Em algumas distribuições, um ficheiro de configuração secundário pode substituir as suas definições. Verifique se existem substituições:
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
Se algum ficheiro nesse diretório definir PasswordAuthentication yes, edite-o ou remova-o.
Valide a sintaxe da configuração antes de reiniciar:
sshd -t
Uma saída limpa (sem erros) significa que é seguro recarregar. Aplique as alterações:
systemctl restart sshd
Aviso crítico: Não feche a sua sessão SSH existente antes de abrir um segundo terminal e confirmar que ainda consegue iniciar sessão com a sua chave. Reiniciar sshd com um ficheiro mal configurado ou antes de a sua chave estar a funcionar irá bloqueá-lo. A maioria dos Painéis de Controlo VPS fornece uma consola de emergência (acesso KVM/VNC) para recuperação, mas é muito melhor evitar completamente a situação.
Passo 8: Gerir Múltiplas Chaves e Servidores com ~/.ssh/config
Ao gerir vários servidores — comum em ambientes de staging/produção ou ao administrar múltiplos Servidores Dedicados — o ficheiro de configuração do cliente SSH elimina a necessidade de memorizar endereços IP, nomes de utilizador e caminhos de chaves.
Crie ou edite ~/.ssh/config na sua máquina local:
nano ~/.ssh/config
Exemplo de configuração para múltiplos hosts:
Host production-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host staging-vps
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    Port 2222

Host legacy-server
    HostName 203.0.113.30
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    PubkeyAcceptedKeyTypes +ssh-rsa
Defina as permissões corretas no ficheiro de configuração:
chmod 600 ~/.ssh/config
Agora pode ligar-se com aliases simples:
ssh production-vps
ssh staging-vps
A diretiva PubkeyAcceptedKeyTypes +ssh-rsa na entrada legada é importante: clientes OpenSSH mais recentes (8.8+) desativam RSA-SHA1 por padrão. Sem esta substituição, as ligações a servidores mais antigos falharão com um erro enigmático de “no matching host key type”.
Resolução de Problemas: Por Que a Autenticação por Chave SSH Falha
Mesmo com uma configuração correta, vários fatores ambientais podem fazer com que a autenticação por chave recorra silenciosamente a pedidos de palavra-passe:
Permissões erradas em .ssh ou authorized_keys:
Execute ls -la ~/.ssh/ no servidor. O diretório deve ser 700 e o ficheiro deve ser 600. Permissões mais permissivas fazem com que o OpenSSH ignore o ficheiro.
Incompatibilidade de contexto SELinux ou AppArmor:
Em sistemas RHEL/CentOS/AlmaLinux com SELinux em modo de aplicação, o ficheiro authorized_keys pode ter o contexto de segurança errado. Restaure-o com:
restorecon -Rv ~/.ssh
Diretório home do utilizador errado:
Se o diretório home do utilizador não for gravável apenas pelo proprietário, o SSH recusará a autenticação por chave. Verifique com:
ls -ld ~
O próprio diretório home não deve ter permissões de escrita para o grupo ou para todos.
Diretiva AuthorizedKeysFile a apontar para outro local:
Algumas distribuições configuram AuthorizedKeysFile para usar um caminho não padrão (ex.: /etc/ssh/authorized_keys/%u). Verifique a definição ativa:
sshd -T | grep authorizedkeysfile
Múltiplas chaves e conflitos com ssh-agent:
Se ssh-agent estiver em execução com várias chaves carregadas, o servidor pode rejeitar a ligação após demasiadas tentativas de chave falhadas antes de tentar a correta. Use -i para especificar a chave explicitamente, ou configure IdentitiesOnly yes em ~/.ssh/config.
Firewall ou fail2ban a bloquear o seu IP:
Se tiver falhado múltiplas tentativas de login anteriormente, regras do fail2ban ou ufw/iptables podem ter banido temporariamente o seu IP. Verifique com:
fail2ban-client status sshd
Rotação e Revogação de Chaves SSH
A rotação de chaves é uma prática de higiene de segurança frequentemente negligenciada. Para revogar uma chave específica, abra ~/.ssh/authorized_keys no servidor e elimine a linha correspondente. Cada linha é uma chave — removê-la revoga imediatamente o acesso ao detentor dessa chave privada sem afetar quaisquer outras chaves autorizadas.
Para fins de auditoria, use comentários distintos em cada chave (a parte após o material da chave, ex.: alice@workstation-2024) para poder identificar qual chave pertence a qual pessoa ou dispositivo. Quando um funcionário sai ou um dispositivo é desativado, localize a sua chave pelo comentário e remova-a.
Para rodar a sua própria chave, gere um novo par, adicione a nova chave pública a authorized_keys, verifique que o login funciona com a nova chave e depois remova a entrada da chave antiga.
Lista de Verificação Prática

Gere chaves Ed25519 por padrão; use RSA 4096 apenas para compatibilidade com servidores legados
Proteja sempre a sua chave privada com uma frase-passe forte
Use ssh-copy-id para uma implementação de chaves rápida e sem erros sempre que possível
Verifique se as permissões do diretório .ssh são 700 e se authorized_keys é 600

FAQ

Posso adicionar múltiplas chaves públicas SSH à mesma conta de utilizador VPS?

Sim. Cada linha em ~/.ssh/authorized_keys é uma chave autorizada independente. Adicione uma chave por linha. Esta é a abordagem padrão para conceder acesso a múltiplos administradores ou a partir de múltiplos dispositivos — cada pessoa ou dispositivo possui uma chave privada única, e a revogação é por linha.

O que acontece se perder a minha chave privada após desativar a autenticação por palavra-passe?

Ficará bloqueado do SSH. A recuperação requer o uso do acesso à consola out-of-band do seu fornecedor de alojamento (KVM/VNC), disponível na maioria dos painéis de controlo de VPS Hosting. A partir da consola, reative PasswordAuthentication yes em /etc/ssh/sshd_config, reinicie sshd e carregue uma nova chave. É por isso que testar o login por chave antes de desativar as palavras-passe é inegociável.

O Ed25519 é suportado em todos os servidores?

O Ed25519 requer OpenSSH 6.5 ou posterior (lançado em 2014). Qualquer distribuição Linux moderna — Ubuntu 18.04+, Debian 9+, CentOS 7+, AlmaLinux 8+ — suporta-o nativamente. Apenas sistemas genuinamente antigos requerem fallback para RSA.

Devo usar o mesmo par de chaves SSH para todos os servidores que giro?

É operacionalmente conveniente, mas cria um único ponto de comprometimento. Uma prática melhor é usar um par de chaves por função ou ambiente (ex.: uma chave para servidores pessoais, outra para infraestrutura de clientes). Isto limita o raio de impacto caso uma chave privada seja alguma vez exposta.

Carregar uma chave SSH afeta os meus Certificados SSL ou a configuração do servidor web?

Não. As chaves SSH regem o acesso terminal ao sistema operativo e são completamente separadas dos certificados TLS/SSL usados pelos servidores web (Apache, Nginx) para HTTPS. Utilizam portas diferentes (22 vs. 443), formatos de chave diferentes e cadeias de confiança diferentes. Alterar uma não tem qualquer efeito na outra.