VPS · 8 min de leitura · Atualizado em mai. de 2026 · Equipe Hostini

SSH com autenticação por chave sem senha: guia completo Ed25519

Configure SSH com autenticação por chave sem senha usando Ed25519 ou RSA, desative login por senha e proteja servidores Linux contra brute force.

Senha no SSH é a maior superfície de ataque de brute force que um servidor Linux exposto à internet enfrenta. Logs de qualquer VPS com porta 22 aberta na internet mostram milhares de tentativas por dia vindas de botnets escaneando faixas inteiras de IP em busca de combinações comuns. A defesa definitiva não é uma senha mais forte — é eliminar autenticação por senha do servidor e aceitar somente chaves criptográficas.

Este tutorial é pra sysadmins e desenvolvedores que administram VPS ou servidores dedicados Linux e querem migrar pra autenticação por chave pública. Você vai gerar um par de chaves Ed25519 na sua máquina local, copiar a chave pública pro servidor, validar o login por chave numa sessão paralela e só então desativar PasswordAuthentication com segurança — o procedimento evita que você fique trancado fora caso algo dê errado na configuração.

Tempo estimado: 15-20 minutos do zero, assumindo que você já tem acesso SSH ativo via senha no servidor de destino.

Pré-requisitos

O que você precisa antes de começar

Acesso SSH ativo ao servidor via senha (root ou usuário com sudo), uma máquina local Linux/macOS/WSL com OpenSSH instalado (ssh -V deve retornar 8.0 ou superior), e dois terminais disponíveis na sua máquina local — vamos manter a sessão original aberta como “rede de segurança” enquanto validamos a nova configuração numa segunda sessão.

Algoritmo recomendado Ed25519

Tamanho da chave 256 bits

OpenSSH mínimo 6.5+ (2014)

Arquivo no servidor ~/.ssh/authorized_keys

Permissão da pasta 700

Permissão do arquivo 600

Gerando o par de chaves Ed25519

A geração de chaves acontece na sua máquina local (cliente), não no servidor. A chave privada nunca deve sair da máquina onde foi gerada — só a pública circula. Ed25519 é o padrão moderno: chaves de 32 bytes, assinatura mais rápida que RSA-4096 e resistência criptográfica equivalente a RSA-3072.

Abra o terminal na sua máquina local e execute:

ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_hostini

O parâmetro -t ed25519 define o algoritmo, -C adiciona um comentário identificador (geralmente seu email — fica embutido na chave pública e ajuda a identificar a origem em listas de chaves), e -f define o nome do arquivo. Use um nome específico em vez do default id_ed25519 se você gerencia múltiplos servidores e quer separar chaves.

Defina uma passphrase forte quando solicitado:

Enter passphrase (empty for no passphrase): [digite passphrase forte]
Enter same passphrase again: [confirme]

A passphrase criptografa a chave privada em disco — se alguém copiar o arquivo ~/.ssh/id_ed25519_hostini, ainda precisa da passphrase pra usá-la. Não pule essa etapa. Use 4-6 palavras aleatórias ou uma frase longa — o ssh-agent (próxima seção) faz com que você digite isso uma vez por sessão, não a cada login.

Confirme que os dois arquivos foram criados:

ls -la ~/.ssh/id_ed25519_hostini*

Você deve ver id_ed25519_hostini (privada, permissão 600) e id_ed25519_hostini.pub (pública, permissão 644). A privada NUNCA sai dessa máquina — não envie por email, não suba no Git, não copie pra pendrive. Backup só em gerenciador de senhas criptografado ou cofre offline.

Copiando a chave pública pro servidor

O método canônico é ssh-copy-id, que adiciona a chave pública no ~/.ssh/authorized_keys do usuário remoto, criando o arquivo com permissões corretas se ele não existir. Você precisará digitar a senha SSH atual uma última vez.

Execute na máquina local (substitua usuário e IP):

ssh-copy-id -i ~/.ssh/id_ed25519_hostini.pub [email protected]

Se você usa porta SSH não-padrão: ssh-copy-id -i ~/.ssh/id_ed25519_hostini.pub -p 2222 [email protected]. O comando faz SSH no servidor (autenticando por senha), anexa a chave pública ao ~/.ssh/authorized_keys, ajusta permissões de ~/.ssh pra 700 e do arquivo pra 600 — qualquer permissão mais permissiva faz o sshd rejeitar a chave silenciosamente.

Se ssh-copy-id não estiver disponível (raro em macOS antigo), use o método manual:

cat ~/.ssh/id_ed25519_hostini.pub | ssh [email protected] \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Esse pipe envia o conteúdo da chave pública via stdin, cria a pasta .ssh com permissão correta se não existir, anexa a chave ao arquivo authorized_keys (sem sobrescrever chaves anteriores) e ajusta a permissão final.

Esta etapa é crítica. Você precisa confirmar que o login por chave funciona ANTES de desabilitar a senha — caso contrário, qualquer erro de permissão ou typo no servidor te tranca fora.

Abra um SEGUNDO terminal (mantenha o primeiro logado como rede de segurança) e tente conectar usando a chave:

ssh -i ~/.ssh/id_ed25519_hostini [email protected]

Você será solicitado a digitar a passphrase da chave (não a senha do servidor). Se logar com sucesso e cair no shell do servidor, a autenticação por chave está funcionando. Se o servidor pedir senha do usuário em vez da passphrase, algo está errado — não prossiga.

Se aparecer 'Permission denied (publickey,password)'

Verifique no servidor: ls -la ~/.ssh/ deve mostrar pasta com permissão 700 e authorized_keys com 600. Dono dos arquivos deve ser o próprio usuário (não root). Logs em /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL/Rocky) mostram a razão exata da rejeição — geralmente é “bad ownership or modes”.

Configurando ssh-agent pra não digitar passphrase toda hora

Sem ssh-agent, você digita a passphrase a cada conexão SSH — o que é tedioso e leva a passphrases curtas e fracas. O agent mantém a chave descriptografada em memória durante a sessão.

Adicione a chave ao agent na máquina local:

ssh-add ~/.ssh/id_ed25519_hostini

No macOS, use ssh-add --apple-use-keychain ~/.ssh/id_ed25519_hostini pra integrar com o Keychain — a passphrase fica guardada permanentemente e o agent abre sem prompt em reboots. No Linux, adicione eval "$(ssh-agent -s)" ao ~/.bashrc se o agent não iniciar automaticamente.

Crie um arquivo ~/.ssh/config pra simplificar conexões:

Host hostini-prod
    HostName 45.xxx.xxx.xxx
    User usuario
    Port 22
    IdentityFile ~/.ssh/id_ed25519_hostini
    IdentitiesOnly yes

Agora você conecta com ssh hostini-prod em vez do comando completo. IdentitiesOnly yes força o uso somente da chave especificada — sem isso, o agent oferece TODAS as chaves carregadas ao servidor, o que pode causar “Too many authentication failures” em servidores com MaxAuthTries baixo.

Desativando autenticação por senha no servidor

Com login por chave validado, agora é seguro desabilitar autenticação por senha. Edite o arquivo /etc/ssh/sshd_config no servidor.

Conecte no servidor pela sessão validada (chave) e edite a configuração:

sudo nano /etc/ssh/sshd_config

Procure e ajuste as seguintes diretivas (descomente removendo o # se necessário):

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes

PermitRootLogin prohibit-password permite root via chave mas bloqueia root via senha — útil pra automação que precisa de root. Se você não precisa de root via SSH (recomendado), use PermitRootLogin no e faça sudo no usuário comum.

Valide a sintaxe antes de reiniciar o serviço:

sudo sshd -t

Output vazio = configuração válida. Se aparecer erro, NÃO reinicie o sshd — corrija primeiro. Reiniciar sshd com config inválida pode deixar o servidor sem SSH ativo até reboot.

Reinicie o serviço SSH:

sudo systemctl restart sshd

Em Ubuntu/Debian recentes, o serviço pode se chamar ssh em vez de sshd — sudo systemctl restart ssh. A sessão atual NÃO é desconectada pelo reinício — sshd só aplica as novas regras a conexões novas.

Não feche o terminal ainda

Mantenha a sessão atual aberta. Abra um TERCEIRO terminal e tente conectar do zero com sua chave. Se funcionar, a configuração está completa. Se falhar, use a sessão original (ainda aberta) pra reverter PasswordAuthentication yes e reiniciar sshd. Só feche todas as sessões depois de validar que conexões novas funcionam.

Verificação final

Confirme que o servidor agora rejeita senha:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no [email protected]

Output esperado: Permission denied (publickey). Esse comando força o cliente a tentar apenas senha, ignorando chaves — se o servidor responde recusando, está corretamente configurado pra aceitar apenas chave pública. Tente também a conexão normal com chave (ssh hostini-prod) — deve logar sem prompt de senha do servidor (só passphrase se o agent não tiver a chave).

Resolução de problemas

”Permission denied” mesmo com chave correta

Verifique permissões no servidor (causa mais comum):

stat -c "%a %n" ~/.ssh ~/.ssh/authorized_keys
# Esperado: 700 /home/usuario/.ssh
#           600 /home/usuario/.ssh/authorized_keys

Se diferente, corrija com chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys. SELinux em servidores RHEL/Rocky pode bloquear leitura mesmo com permissões corretas — restorecon -R ~/.ssh aplica contexto correto.

”Too many authentication failures”

Acontece quando ssh-agent tenta várias chaves antes de chegar na certa. Force apenas a chave correta:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_hostini usuario@servidor

Ou adicione IdentitiesOnly yes no ~/.ssh/config da máquina local conforme mostrado no passo 8.

Trancado fora após desabilitar senha

Use o console web do painel da VPS pra acessar o servidor diretamente (bypass do SSH), edite /etc/ssh/sshd_config revertendo PasswordAuthentication yes, reinicie o serviço e investigue o problema com calma. Em provedores que oferecem console serial, esse é o método de recuperação oficial.

Próximos passos

Configure fail2ban pra bloquear tentativas suspeitas em outras superfícies (HTTP, SMTP) — SSH não precisa mais com senha desabilitada
Mude a porta SSH padrão (22 → 2222 ou similar) — reduz ruído de logs em ~95%, embora não aumente segurança real
Configure 2FA via TOTP no SSH com pam_google_authenticator pra camada adicional em servidores críticos
Documente as chaves autorizadas em cada servidor — chaves abandonadas de ex-funcionários são vetor real de incidente
Considere SSH certificates com CA própria se você gerencia frota de 20+ servidores — escala melhor que distribuir chaves manualmente

Se você está colocando isso em produção numa VPS Hostini, todos os planos VPS já vêm com console web de emergência integrado ao painel — fallback seguro caso uma configuração SSH te tranque fora.

Perguntas frequentes

Ed25519 ou RSA: qual escolher em 2026?

Ed25519 é o padrão recomendado pra qualquer servidor novo — chaves de 32 bytes, geração instantânea, assinatura mais rápida que RSA-4096 e resistência criptográfica equivalente. Use RSA-4096 só se precisar interoperar com sistemas legados (OpenSSH < 6.5, alguns appliances de rede antigos) que ainda não suportam Ed25519. RSA-2048 não é mais aceitável pra produção.

Posso usar a mesma chave SSH em vários servidores?

Tecnicamente sim, e é comum usar uma chave por máquina cliente (laptop, desktop) replicada em N servidores. O risco: se o cliente é comprometido, o atacante acessa tudo. Mitigação: proteger a chave privada com passphrase forte e usar ssh-agent. Ambientes mais sensíveis (produção crítica) podem isolar com uma chave por grupo de servidores.

O que acontece se eu perder minha chave privada?

Sem a chave privada e sem outro método de acesso, você fica trancado fora — não existe recuperação criptográfica. Por isso o tutorial insiste em manter PasswordAuthentication ativo até validar o login por chave numa sessão paralela. Em VPS, você sempre tem o console web do painel como fallback de emergência pra reverter a configuração.

Preciso desativar o login por senha mesmo com fail2ban instalado?

Sim. Fail2ban reduz a taxa de tentativas, mas não elimina o vetor — um atacante com botnet distribuída de milhares de IPs contorna o limiar de tentativas. Desativar PasswordAuthentication elimina a categoria inteira de ataques de força bruta contra senha. Fail2ban continua útil pra outras superfícies (HTTP, SMTP).

Como funciona o ssh-agent e por que vale a pena usar?

ssh-agent é um daemon que mantém suas chaves descriptografadas em memória durante a sessão, então você digita a passphrase uma vez e usa a chave N vezes sem redigitar. No macOS o agent integra com Keychain; no Linux, inicia junto com a sessão gráfica. Em servidores intermediários, ssh-agent com ForwardAgent permite saltar pra hosts internos sem copiar a chave privada — mas use com moderação por segurança.

Posso restringir uma chave SSH a comandos específicos?

Sim. O arquivo ~/.ssh/authorized_keys aceita opções antes da chave: command="rsync ..." força execução de um único comando, from="1.2.3.4" restringe IPs de origem, no-port-forwarding e no-X11-forwarding desabilitam features. Útil pra chaves de automação (backup, deploy) que não devem dar shell interativo se a chave vazar.

Tópicos:

vps linux ssh

Próximos passos Cloud Ryzen com NVMe e proteção DDoS sempre ativa.Coloque em produção numa VPS Hostini →

Esse tutorial foi útil?