Como configurar acesso SSH por chave no Ubuntu VPS

Resposta rápida

O caminho seguro é criar uma chave Ed25519 no computador administrador, instalar somente a chave pública no usuário do servidor, abrir uma nova sessão de teste e apenas depois alterar o sshd. Nunca feche a sessão original antes de confirmar que a nova autenticação funciona.

Veja a infraestrutura: VPS com monitoramento e backup semanal para colocar este projeto no ar.

Por que trocar senha por chave

Senhas podem ser reutilizadas, expostas em gerenciadores mal configurados ou submetidas a tentativas automatizadas. A chave privada permanece no cliente e a chave pública pode ficar no servidor. Isso não elimina a necessidade de atualizações, firewall e menor privilégio, mas reduz uma superfície comum de ataque.

1. Gere a chave no computador administrador

No macOS ou Linux:

ssh-keygen -t ed25519 -C "admin-vps"

Aceite o caminho padrão ou informe um arquivo separado para cada ambiente. Use uma frase secreta forte. A chave privada não deve ser enviada por e-mail, commitada no Git ou copiada para o VPS.

Confira os arquivos:

ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

2. Instale a chave pública

Se ssh-copy-id estiver disponível:

ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@IP_DO_VPS

Alternativamente, conecte com a senha atual e execute no servidor:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
printf '%s\n' 'COLE_AQUI_A_CHAVE_PUBLICA' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Garanta que o arquivo pertença ao usuário correto:

chown -R usuario:usuario ~/.ssh

3. Teste sem encerrar a sessão original

Abra outro terminal e force a chave:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 usuario@IP_DO_VPS

Se falhar, veja os logs no Ubuntu:

sudo journalctl -u ssh -n 80 --no-pager

Permissões incorretas em ~/.ssh e authorized_keys, usuário errado e chave colada com quebra de linha são causas frequentes.

4. Endureça o servidor depois da validação

Faça backup e edite uma configuração em arquivo separado:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudoedit /etc/ssh/sshd_config.d/99-hardening.conf

Exemplo conservador:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

Valide antes de recarregar:

sudo sshd -t
sudo systemctl reload ssh

Mantenha o console de recuperação do provedor disponível. Se perder todas as sessões, restaure o backup pelo console, não tente adivinhar alterações de firewall ou SSH.

Checklist final

• [ ] Chave privada protegida por frase secreta.
• [ ] Chave pública instalada no usuário certo.
• [ ] Nova sessão testada com IdentitiesOnly=yes.
• [ ] sshd -t passou antes do reload.
• [ ] Console de recuperação conhecido.

Uma VPS é mais fácil de operar quando o acesso administrativo tem um procedimento repetível. Veja os planos de VPS e dimensione o ambiente de acordo com a aplicação, não apenas com o número de conexões SSH.

FAQ

Posso apagar a senha imediatamente?

Não. Primeiro teste uma segunda sessão com a chave e mantenha uma forma de recuperação. Só depois desative a senha.

Ed25519 funciona em todo cliente?

Funciona nos clientes OpenSSH atuais. Em equipamentos antigos, confirme a versão antes de padronizar a política.

Decisão operacional

Para uma única VPS, uma chave por administrador e um usuário sem privilégio de root costumam ser mais fáceis de auditar do que compartilhar uma chave. Para uma equipe, registre o responsável por cada chave e remova acessos de pessoas que deixam o projeto. O arquivo authorized_keys aceita comentários que ajudam na identificação, mas o comentário não é uma permissão. Combine a chave com firewall, atualizações, MFA no painel do provedor e logs centralizados. O objetivo é tornar o acesso revogável e recuperável, não apenas trocar uma senha por um arquivo.