Como Adicionar Chaves SSH a um VPS Novo ou Existente

As chaves SSH são pares de chaves criptográficas — uma chave pública armazenada no servidor e uma chave privada mantida na sua máquina local — que autenticam a sua identidade sem transmitir uma palavra-passe pela rede. Quando se liga, o servidor emite um desafio criptográfico que apenas a sua chave privada consegue resolver, concedendo acesso se a resposta for válida. Este mecanismo torna a autenticação por chave SSH fundamentalmente mais resistente a ataques de força bruta, preenchimento de credenciais e interceção man-in-the-middle do que qualquer esquema baseado em palavra-passe.

Este guia abrange o processo completo de geração, implementação e reforço da autenticação por chave SSH em instâncias VPS novas e existentes — incluindo casos extremos, armadilhas de permissões e gestão de múltiplas chaves que a maioria dos tutoriais ignora completamente.

Por Que as Chaves SSH São Arquiteturalmente Superiores às Palavras-passe

A autenticação por palavra-passe envia um segredo (ou o seu hash) pela rede e depende do servidor armazenar uma credencial verificável. A autenticação por chave pública SSH nunca expõe a chave privada — nem durante a geração, nem durante o início de sessão, nunca. A chave privada nunca sai da sua máquina local.

Além da segurança básica, as chaves SSH desbloqueiam capacidades operacionais que as palavras-passe não conseguem:

• Automação sem supervisão — Pipelines CI/CD, playbooks Ansible e tarefas rsync agendadas por cron requerem autenticação não interativa. As palavras-passe inviabilizam completamente isto.
• Controlo de acesso granular — Cada entrada authorized_keys pode incluir restrições command=, from= e no-pty, limitando exatamente o que uma determinada chave tem permissão para fazer.
• Auditabilidade — Chaves individuais podem ser revogadas sem alterar uma palavra-passe partilhada e sem perturbar todos os outros utilizadores ou scripts.
• Resistência ao phishing — Não existe palavra-passe para roubar através de uma página de início de sessão falsa.

Pré-requisitos

Antes de prosseguir, confirme o seguinte:

• Tem um VPS em execução ou está em processo de aprovisionamento de um.
• A sua máquina local executa Linux, macOS ou Windows com OpenSSH instalado (o Windows 10/11 inclui OpenSSH por predefinição; verifique com ssh -V).
• Tem acesso root ou sudo ao servidor de destino.
• Compreende que perder a sua chave privada sem um método de início de sessão alternativo (acesso à consola, chave de recuperação) pode bloqueá-lo permanentemente.

Escolher o Algoritmo de Chave Correto

O comando original ssh-keygen -t rsa -b 4096 é sólido, mas não é a única opção. Compreender as trocas ajuda-o a fazer a escolha certa para o seu ambiente.

Ed25519 é o algoritmo recomendado para qualquer servidor que execute OpenSSH 6.5 ou posterior (lançado em 2014). Use RSA 4096 apenas quando se ligar a sistemas legados que não suportam chaves de curva elíptica.

Parte 1: Adicionar Chaves SSH a um Novo VPS

Muitos painéis de controlo de alojamento permitem injetar uma chave pública no momento do aprovisionamento, antes de a instância arrancar. Esta é a abordagem mais limpa — a chave é incorporada na imagem e a autenticação por palavra-passe pode nunca precisar de ser ativada.

Passo 1: Gerar o Seu Par de Chaves SSH

Abra um terminal na sua máquina local. Gere um par de chaves Ed25519:

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

Se precisar de RSA por razões de compatibilidade:

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

Quando solicitado um local para o ficheiro, prima Enter para aceitar o predefinido (~/.ssh/id_ed25519 ou ~/.ssh/id_rsa). Quando solicitado uma frase-passe, defina uma — ela encripta a chave privada no disco, portanto, mesmo que o seu portátil seja roubado, a chave é inútil sem a frase-passe. O seu agente SSH (ssh-agent) irá guardar em cache a chave desencriptada na memória para que apenas precise de digitar a frase-passe uma vez por sessão.

Verifique os ficheiros gerados:

ls -la ~/.ssh/

Verá:

• id_ed25519 — a sua chave privada (as permissões devem ser 600; nunca partilhe este ficheiro)
• id_ed25519.pub — a sua chave pública (segura para copiar para qualquer lugar)

Exiba a chave pública para a copiar:

cat ~/.ssh/id_ed25519.pub

O resultado tem este aspeto:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

Copie esta cadeia completa — irá colá-la no seu painel de alojamento.

Passo 2: Adicionar a Chave Pública Durante o Aprovisionamento do VPS

Inicie sessão no seu painel de controlo de alojamento. Durante o fluxo de criação do VPS:

1. Selecione o seu sistema operativo (Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9, etc.).
2. Localize a secção Chave SSH ou Autenticação.
3. Cole o conteúdo completo de id_ed25519.pub no campo fornecido.
4. Conclua a configuração restante (plano, região, nome do host).

Assim que o VPS arrancar, o sistema de aprovisionamento escreve a sua chave pública em /root/.ssh/authorized_keys automaticamente. Não é necessário início de sessão por palavra-passe.

Passo 3: Ligar ao VPS Recém-Aprovisionado

ssh root@your_vps_ip

Se utilizou um nome de ficheiro de chave não predefinido, especifique-o explicitamente:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Uma ligação bem-sucedida sem pedido de palavra-passe confirma que a chave foi injetada corretamente. Se definiu uma frase-passe, o seu agente SSH ou um pedido de frase-passe tratará disso localmente.

Parte 2: Adicionar Chaves SSH a um VPS Existente

Se o seu VPS já está em execução com autenticação por palavra-passe, precisa de implementar manualmente a chave pública. Este é um processo em duas fases: copiar a chave e, em seguida, opcionalmente reforçar o daemon SSH.

Passo 1: Gerar um Par de Chaves (Se Não Tiver Um)

Siga o mesmo processo do Passo 1 na Parte 1 acima. Se já tiver um par de chaves, recupere a sua chave pública:

cat ~/.ssh/id_ed25519.pub

Passo 2: Copiar a Chave Pública para o Servidor

Método A — ssh-copy-id (Recomendado)

O utilitário ssh-copy-id trata automaticamente da criação de diretórios, adição ao ficheiro e definição de permissões:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip

Introduza a sua palavra-passe quando solicitado. A ferramenta adiciona a chave a ~/.ssh/authorized_keys no servidor remoto e define as permissões corretas. Este é o método mais seguro porque evita sobrescritas acidentais de chaves existentes.

Método B — Implementação Manual

Utilize este método quando ssh-copy-id não está disponível (por exemplo, em alguns ambientes Windows ou redes restritas):

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"

Este pipeline único é mais seguro do que abrir um editor de texto no servidor remoto porque adiciona em vez de sobrescrever.

Método C — Manual via Editor de Texto (Alternativa)

Inicie sessão no servidor com a sua palavra-passe:

ssh root@your_vps_ip

Crie o diretório .ssh se não existir:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Abra authorized_keys num editor de texto:

nano ~/.ssh/authorized_keys

Cole a sua chave pública numa nova linha. Guarde com Ctrl+X, depois Y, depois Enter. Defina as permissões:

chmod 600 ~/.ssh/authorized_keys

Termine a sessão:

exit

Passo 3: Verificar o Início de Sessão Baseado em Chave

Teste a ligação antes de fazer quaisquer alterações adicionais ao daemon SSH. Abra uma nova janela de terminal (não feche a sessão existente ainda):

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Se se ligar sem pedido de palavra-passe, a chave está a funcionar. Só prossiga para os passos de reforço abaixo após confirmar isto.

Armadilha crítica: Se desativar a autenticação por palavra-passe antes de verificar o acesso por chave, e a implementação da chave falhou por algum motivo, ficará bloqueado. Teste sempre primeiro.

Passo 4: Reforçar a Configuração do Daemon SSH

Assim que o acesso baseado em chave for confirmado, abra o ficheiro de configuração do daemon SSH:

nano /etc/ssh/sshd_config

Aplique as seguintes definições:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes

Notas importantes sobre estas diretivas:

• PermitRootLogin prohibit-password permite o início de sessão root via chave mas bloqueia o início de sessão root por palavra-passe — um meio-termo melhor do que PermitRootLogin no quando ainda está a configurar um utilizador sudo não-root.
• ChallengeResponseAuthentication no desativa a autenticação interativa por teclado, que pode contornar PasswordAuthentication no em algumas configurações PAM.
• No Ubuntu 22.04+, o ficheiro /etc/ssh/sshd_config.d/50-cloud-init.conf pode substituir as suas definições. Verifique e edite-o se necessário.

Valide a sintaxe da configuração antes de reiniciar:

sshd -t

Se não forem reportados erros, reinicie o serviço SSH:

systemctl restart sshd

Em sistemas que utilizam ssh.service em vez de sshd.service:

systemctl restart ssh

Gerir Múltiplas Chaves SSH e Utilizadores

Os ambientes do mundo real raramente envolvem uma única chave e um único utilizador. Eis como lidar com cenários mais complexos.

Adicionar Chaves para Múltiplos Utilizadores

Cada conta de utilizador tem o seu próprio ficheiro ~/.ssh/authorized_keys. Para adicionar uma chave para um utilizador não-root chamado deploy:

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
echo "ssh-ed25519 AAAAC3... deploy@ci-server" >> /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

O passo chown é frequentemente esquecido e causa falhas de autenticação — o SELinux e o OpenSSH verificam ambos que o ficheiro authorized_keys é propriedade do utilizador que está a autenticar.

Restringir o Que uma Chave Pode Fazer

Pode prefixar qualquer linha em authorized_keys com opções para limitar as suas capacidades. Isto é especialmente útil para chaves de implementação ou automação de cópias de segurança:

command="/usr/bin/rsync --server --daemon .",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3... backup@monitoring

Esta chave só pode executar rsync em modo daemon — nada mais.

Utilizar ~/.ssh/config para Ligações Mais Simples

Em vez de digitar comandos ssh longos, defina aliases de host na sua máquina local:

Host myserver
    HostName 203.0.113.45
    User root
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Depois de guardar isto em ~/.ssh/config, ligue-se simplesmente com:

ssh myserver

Utilizar ssh-agent para Guardar em Cache as Frases-passe

Se a sua chave privada tiver uma frase-passe (deve ter), adicione-a ao agente para não ser solicitado repetidamente:

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

No macOS, adicione --apple-use-keychain para persistir entre reinicializações:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Armadilhas Comuns e Resolução de Problemas

Problema: Ainda é solicitada uma palavra-passe após adicionar a chave

Execute a ligação com saída detalhada para diagnosticar:

ssh -vvv root@your_vps_ip

Procure linhas como Offering public key e Server accepts key. Se a chave for oferecida mas rejeitada, o problema é quase sempre as permissões de ficheiro no servidor.

Verifique as permissões no servidor:

ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

Permissões necessárias:

• ~/.ssh/ — 700 (drwx——)
• ~/.ssh/authorized_keys — 600 (-rw——-)
• Diretório home ~/ — não deve ter permissão de escrita para todos (755 ou 750)

Problema: SELinux a bloquear autenticação no RHEL/Rocky/AlmaLinux

restorecon -Rv ~/.ssh

Problema: O ficheiro authorized_keys tem terminações de linha Windows (CRLF)

Se editou o ficheiro no Windows e o transferiu, as terminações de linha podem estar corrompidas. Corrija com:

sed -i 's/r//' ~/.ssh/authorized_keys

Problema: Chave errada a ser oferecida

Se tiver múltiplas chaves, especifique a correta explicitamente:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Ou configure-a em ~/.ssh/config conforme mostrado acima.

Chaves SSH no Contexto da Sua Infraestrutura de Alojamento

A autenticação por chave SSH não é apenas uma preocupação de servidor único — escala por toda a sua infraestrutura. Se gerir uma frota de servidores dedicados, uma abordagem centralizada usando ferramentas como Ansible, Puppet ou um gestor de segredos (HashiCorp Vault, AWS Secrets Manager) para distribuir e rodar chaves autorizadas é essencial.

Para equipas que executam aplicações web em VPS com cPanel, a interface de Acesso SSH do cPanel na secção de Segurança fornece uma GUI para gerar e gerir pares de chaves — útil para programadores que não estão confortáveis com a linha de comandos mas ainda precisam de acesso seguro.

Se estiver a executar cargas de trabalho intensivas em GPU em infraestrutura de alojamento GPU, a autenticação por chave SSH é especialmente crítica porque estas instâncias frequentemente executam tarefas de longa duração sem supervisão. Uma credencial comprometida num servidor GPU pode resultar em custos de computação não autorizados significativos, além da exposição de dados.

Combinar o reforço SSH com um certificado SSL válido em quaisquer serviços voltados para a web a correr no mesmo servidor fecha os dois vetores de ataque mais comuns simultaneamente — acesso shell não autenticado e tráfego HTTP não encriptado.

Para projetos que utilizam alojamento web partilhado que também precisam de acesso SSH, verifique se o seu fornecedor suporta injeção de chave SSH através do painel de alojamento, pois os ambientes partilhados frequentemente restringem o SSH a utilizadores específicos com acesso shell limitado.

Rotação de Chaves e Gestão de Chaves a Longo Prazo

As chaves SSH não expiram automaticamente. Sem uma política de rotação, uma chave comprometida há anos pode ainda conceder acesso. Estabeleça estas práticas:

• Rode as chaves anualmente ou imediatamente em caso de suspeita de comprometimento.
• Audite os ficheiros authorized_keys em todos os servidores regularmente. Remova chaves pertencentes a ex-funcionários ou serviços desativados.
• Use chaves separadas por dispositivo — não copie a mesma chave privada para múltiplos portáteis ou servidores. Se um dispositivo for perdido, revoga apenas essa chave.
• Use chaves separadas por função — a sua chave de acesso pessoal, a sua chave de implementação CI/CD e a sua chave de automação de cópias de segurança devem ser todas distintas.
• Documente a propriedade das chaves — mantenha um registo que mapeie cada impressão digital de chave pública ao seu proprietário, finalidade e data de expiração.

Para exibir a impressão digital de uma chave para auditoria:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Lista de Verificação de Decisões Técnicas

Use esta matriz antes de finalizar a sua configuração de chave SSH:

• Algoritmo: Use Ed25519 a menos que se ligue a sistemas mais antigos que OpenSSH 6.5; use RSA 4096 como alternativa.
• Frase-passe: Defina sempre uma nas chaves privadas usadas por humanos; as chaves de serviço usadas por automação podem omiti-la se armazenadas num gestor de segredos.
• Método de implementação: Use ssh-copy-id para configurações interativas; use gestão de configuração (Ansible, Puppet) para implementações em frota.
• Verificação de permissões: Confirme 700 em ~/.ssh/, 600 em authorized_keys, e propriedade correta antes de desativar a autenticação por palavra-passe.
• Teste antes de bloquear: Verifique sempre o início de sessão por chave numa sessão de terminal separada antes de definir PasswordAuthentication no.
• Validação da configuração do daemon: Execute sshd -t antes de reiniciar o serviço SSH para detetar erros de sintaxe.
• Desativar autenticação por palavra-passe: Defina PasswordAuthentication no e ChallengeResponseAuthentication no em conjunto — um sozinho é insuficiente em sistemas com PAM ativado.
• Política de início de sessão root: Prefira PermitRootLogin prohibit-password em vez de PermitRootLogin yes; migre para um utilizador sudo não-root e defina PermitRootLogin no como estado final reforçado.
• Rotação de chaves: Agende rotação anual; revogue imediatamente em caso de perda de dispositivo ou mudança de pessoal.
• Auditoria: Execute periodicamente grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys para rever todas as chaves autorizadas no sistema.

FAQ

Posso adicionar múltiplas chaves SSH ao mesmo servidor?

Sim. Cada linha em ~/.ssh/authorized_keys representa uma chave pública autorizada. Pode adicionar tantas chaves quantas necessárias — uma por linha. Isto permite que múltiplos administradores ou múltiplos dispositivos se autentiquem de forma independente, e pode revogar qualquer chave individual eliminando a sua linha sem afetar as outras.

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 aceder ao servidor através de um método fora de banda: a consola web do seu fornecedor de alojamento, VNC ou um ambiente de arranque de recuperação. A partir daí pode reativar a autenticação por palavra-passe ou adicionar uma nova chave pública. É por isso que manter as credenciais de acesso à consola seguras e separadas é essencial.

O Ed25519 é suportado em todos os servidores?

O Ed25519 requer OpenSSH 6.5 ou posterior, lançado em janeiro de 2014. Qualquer servidor que execute uma distribuição Linux moderna (Ubuntu 18.04+, Debian 9+, CentOS 7+, Rocky Linux 8+) suporta-o. O único cenário que requer RSA é a ligação a sistemas genuinamente legados ou dispositivos embebidos com versões desatualizadas do OpenSSH.

Adicionar uma chave SSH desativa automaticamente o início de sessão por palavra-passe?

Não. Adicionar uma chave a authorized_keys ativa o início de sessão baseado em chave mas não desativa a autenticação por palavra-passe. Deve definir explicitamente PasswordAuthentication no em /etc/ssh/sshd_config e reiniciar o daemon SSH para impor acesso apenas por chave.

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

Tecnicamente sim, mas não é recomendado para ambientes de produção. Usar uma única chave em muitos servidores significa que comprometer uma chave privada concede acesso a todos eles. A melhor prática é usar chaves por dispositivo (uma chave por estação de trabalho ou portátil) para que perder um dispositivo exija revogar apenas essa chave na sua frota de servidores, em vez de substituir chaves em todo o lado simultaneamente.