Como configurar autenticação SSH com chave pública

Tempo estimado: 15 a 20 minutos
Dificuldade: iniciante

Neste guia, você vai trocar o login SSH baseado em senha por autenticação com chave pública. O procedimento funciona em versões atuais do Ubuntu, Debian, AlmaLinux e Rocky Linux que utilizam OpenSSH.

O que você vai aprender

Ao concluir a configuração, você saberá:

• Criar um par de chaves SSH Ed25519 no computador local.
• Identificar a diferença entre chave privada e chave pública.
• Instalar a chave pública na conta de usuário da VPS.
• Ajustar as permissões exigidas pelo OpenSSH.
• Fazer backup da configuração antes de alterá-la.
• Desabilitar login por senha sem interromper o acesso atual.
• Testar se a VPS aceita a chave e rejeita tentativas por senha.

A chave privada continuará somente no seu computador. A VPS receberá a chave pública, que pode autorizar o acesso, mas não permite reconstruir a parte privada. Esse modelo reduz a exposição a ataques automatizados de força bruta contra senhas.

Pré-requisitos

Você precisa de uma VPS Linux acessível por SSH, uma conta com permissão para executar sudo e a senha atual desse usuário. O computador local pode usar Linux, macOS ou Windows 10 e 11 com o cliente OpenSSH instalado.

Descubra o endereço IP público e o usuário administrativo fornecidos pelo provedor. Nos exemplos, usaremos o IP reservado para documentação 203.0.113.10 e o usuário ubuntu. Substitua esses dois valores pelos dados reais da sua VPS antes de conectar:

export SERVER_IP="203.0.113.10"
export SSH_USER="ubuntu"

Confira se as variáveis foram preenchidas:

printf 'Usuário: %s\nServidor: %s\n' "$SSH_USER" "$SERVER_IP"

A saída deve seguir este formato:

Usuário: ubuntu
Servidor: 203.0.113.10

Mantenha a sessão SSH atual aberta durante todo o procedimento. Abra uma segunda janela de terminal para os testes. Assim, se uma regra estiver incorreta, você ainda poderá corrigir o arquivo pela conexão original.

Caso ainda esteja escolhendo uma máquina, consulte a seleção de melhores VPS no Brasil. Para entender os critérios técnicos usados nas análises, veja como avaliamos serviços de VPS.

Passo 1: Criar uma chave SSH no computador local

Primeiro, confirme que o cliente OpenSSH está disponível no seu computador. Execute este comando localmente, não dentro da VPS:

ssh -V

Você deve receber uma versão semelhante a esta:

OpenSSH_9.6p1, OpenSSL 3.0.13 30 Jan 2024

No Windows PowerShell, a saída também começa com OpenSSH_for_Windows. Se o comando não existir no Ubuntu ou Debian, instale o cliente com sudo apt update && sudo apt install openssh-client. No Windows, ative o recurso Cliente OpenSSH nas configurações de recursos opcionais.

Crie o diretório local que armazenará as chaves e limite seu acesso ao usuário atual:

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

Agora gere uma chave Ed25519 dedicada para a VPS:

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_vps -C "$(whoami)@$(hostname)-vps"

O programa solicitará uma passphrase. Use uma frase longa e exclusiva para proteger a chave privada caso seu computador seja perdido ou comprometido. Ao finalizar, a saída será parecida com:

Generating public/private ed25519 key pair.
Your identification has been saved in /home/ana/.ssh/id_ed25519_vps
Your public key has been saved in /home/ana/.ssh/id_ed25519_vps.pub
The key fingerprint is:
SHA256:8YpQm5B3Yc0y2qQpN5uSvrIvnL1F7AC2kX0aLrM9XvE ana@notebook-vps

Confira os arquivos sem exibir o conteúdo da chave privada:

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

O resultado esperado mostra a chave privada com acesso restrito e a pública legível:

-rw------- 1 ana ana 464 Sep 21 10:15 /home/ana/.ssh/id_ed25519_vps
-rw-r--r-- 1 ana ana 104 Sep 21 10:15 /home/ana/.ssh/id_ed25519_vps.pub

Nunca envie o arquivo id_ed25519_vps para a VPS, por e-mail ou por aplicativos de mensagem. Somente o arquivo terminado em .pub deve ser compartilhado.

Passo 2: Copiar a chave pública para a VPS

Antes de instalar a chave, registre sua impressão digital. Esse identificador ajuda a confirmar posteriormente qual chave foi autorizada:

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

A saída terá o tipo ED25519 e uma impressão SHA256:

256 SHA256:8YpQm5B3Yc0y2qQpN5uSvrIvnL1F7AC2kX0aLrM9XvE ana@notebook-vps (ED25519)

Teste o acesso atual por senha antes de alterar qualquer configuração. Esse teste confirma que IP, usuário e porta estão corretos:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no "$SSH_USER@$SERVER_IP"

Na primeira conexão, confira a impressão digital do servidor no painel do provedor antes de responder yes. Depois de informar a senha, você deverá ver o prompt remoto, por exemplo:

ubuntu@vps-segura:~$

Digite exit para voltar ao computador local. Em seguida, copie a chave pública usando ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519_vps.pub "$SSH_USER@$SERVER_IP"

Informe a senha atual quando solicitado. O utilitário deve confirmar a inclusão:

Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'"

Teste imediatamente a autenticação com a chave específica:

ssh -i ~/.ssh/id_ed25519_vps -o IdentitiesOnly=yes "$SSH_USER@$SERVER_IP"

Você poderá receber uma solicitação da passphrase da chave. Isso acontece no computador local e não é a senha da VPS. Após digitá-la, o prompt remoto deve aparecer sem solicitar a senha da conta Linux.

Dentro da VPS, confirme quem está conectado:

whoami && hostname

Uma saída válida será semelhante a:

ubuntu
vps-segura

Não avance se esse teste falhar. A autenticação por senha ainda será necessária para corrigir o problema, e desabilitá-la agora poderá bloquear seu acesso.

Passo 3: Conferir a chave e corrigir as permissões

Continue conectado à VPS pela chave. O OpenSSH ignora arquivos autorizados quando o diretório .ssh ou o arquivo authorized_keys permite escrita por outros usuários. Por isso, você vai criar um backup e aplicar permissões seguras.

Confirme que o arquivo existe:

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

A saída deve incluir o diretório e o arquivo:

drwx------ 2 ubuntu ubuntu 4096 Sep 21 10:25 /home/ubuntu/.ssh
-rw------- 1 ubuntu ubuntu  104 Sep 21 10:25 /home/ubuntu/.ssh/authorized_keys

Faça uma cópia antes de editar permissões ou conteúdo. Esse comando não remove dados e adiciona data e hora ao nome do backup:

cp -a ~/.ssh/authorized_keys ~/.ssh/authorized_keys.backup.$(date +%Y%m%d%H%M%S)

Verifique se a cópia foi criada:

ls -1t ~/.ssh/authorized_keys* | head

O retorno esperado contém os dois arquivos:

/home/ubuntu/.ssh/authorized_keys.backup.20260921102830
/home/ubuntu/.ssh/authorized_keys

Ajuste o proprietário e as permissões. Os comandos usam a conta conectada, então funcionam mesmo quando o usuário não se chama ubuntu:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$(id -un):$(id -gn)" ~/.ssh

Valide os números das permissões com stat:

stat -c '%a %U:%G %n' ~/.ssh ~/.ssh/authorized_keys

No Linux, você deve receber algo semelhante a:

700 ubuntu:ubuntu /home/ubuntu/.ssh
600 ubuntu:ubuntu /home/ubuntu/.ssh/authorized_keys

Confira também se a chave autorizada tem a mesma impressão digital da chave local. Execute na VPS:

ssh-keygen -lf ~/.ssh/authorized_keys

Compare o valor SHA256 com o registrado no passo anterior. Se houver várias chaves, o comando mostrará uma linha para cada entrada válida. Só continue quando reconhecer a impressão da sua chave.

Passo 4: Desabilitar a autenticação por senha

Agora você vai alterar a configuração do servidor OpenSSH. Uma opção incorreta pode impedir novas conexões. Mantenha a sessão atual aberta e confirme mais uma vez, em outro terminal, que a chave funciona.

Na VPS, localize o arquivo principal e confira se ele carrega o diretório de configurações adicionais:

grep -nE '^Include|^[# ]*PasswordAuthentication' /etc/ssh/sshd_config

Em instalações atuais, uma saída comum é:

12:Include /etc/ssh/sshd_config.d/*.conf
57:#PasswordAuthentication yes

Faça backup do arquivo principal e de qualquer configuração anterior com o mesmo nome:

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%Y%m%d%H%M%S)
sudo test ! -e /etc/ssh/sshd_config.d/99-key-auth.conf || sudo cp -a /etc/ssh/sshd_config.d/99-key-auth.conf /etc/ssh/sshd_config.d/99-key-auth.conf.backup.$(date +%Y%m%d%H%M%S)

Crie o diretório de configuração, caso ele ainda não exista:

sudo install -d -m 0755 /etc/ssh/sshd_config.d

Grave as regras de autenticação:

printf '%s\n' \
  'PubkeyAuthentication yes' \
  'PasswordAuthentication no' \
  'KbdInteractiveAuthentication no' \
  'PermitRootLogin prohibit-password' \
  | sudo tee /etc/ssh/sshd_config.d/99-key-auth.conf

A saída deve repetir as quatro diretivas:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

PasswordAuthentication no bloqueia senhas comuns. KbdInteractiveAuthentication no também bloqueia desafios de senha via teclado interativo. PermitRootLogin prohibit-password permite chave para root, mas rejeita senha. É mais seguro usar um usuário administrativo comum com sudo.

Confirme o conteúdo antes de recarregar o serviço:

sudo cat /etc/ssh/sshd_config.d/99-key-auth.conf

Se o grep inicial não mostrou uma diretiva Include, não recarregue ainda. Adicione Include /etc/ssh/sshd_config.d/*.conf no início do arquivo principal com um editor, ou aplique as quatro diretivas diretamente no final de /etc/ssh/sshd_config após preservar o backup.

Passo 5: Validar e recarregar o serviço SSH

O OpenSSH possui uma verificação de sintaxe que deve ser executada antes de qualquer recarga. Na VPS, rode:

sudo sshd -t

Sucesso não produz saída. Confira o código de retorno:

echo $?

O resultado esperado é:

0

Se aparecer uma mensagem como Bad configuration option ou Missing argument, não recarregue o serviço. Revise a linha informada ou restaure o backup. Sua sessão atual deve permanecer aberta enquanto você corrige o arquivo.

Confira a configuração efetiva, já considerando arquivos incluídos e possíveis diretivas anteriores:

sudo sshd -T | grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

A saída correta será semelhante a:

permitrootlogin without-password
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no

Algumas versões exibem prohibit-password no lugar de without-password. Os dois valores têm o mesmo propósito nesse contexto.

Identifique o nome da unidade do serviço. Ubuntu e Debian normalmente usam ssh, enquanto AlmaLinux e Rocky Linux usam sshd:

if systemctl list-unit-files ssh.service --no-legend 2>/dev/null | grep -q '^ssh.service'; then SERVICE=ssh; else SERVICE=sshd; fi
printf 'Serviço detectado: %s\n' "$SERVICE"

Você verá um dos seguintes resultados:

Serviço detectado: ssh

ou:

Serviço detectado: sshd

Recarregue, sem interromper deliberadamente as conexões existentes:

sudo systemctl reload "$SERVICE"
sudo systemctl is-active "$SERVICE"

O retorno esperado é:

active

Use reload em vez de restart para reduzir o risco de interromper a sessão atual. Mesmo assim, não feche esse terminal. Abra outro e faça os testes finais antes de considerar a alteração concluída.

Verificação e testes

Em uma nova janela do computador local, force o uso da chave criada:

ssh -i ~/.ssh/id_ed25519_vps -o IdentitiesOnly=yes "$SSH_USER@$SERVER_IP"

A conexão deve abrir normalmente. Na VPS, confira o método registrado pelo serviço:

sudo journalctl -u ssh -u sshd --since '5 minutes ago' --no-pager | tail -20

Uma linha típica informa autenticação por chave pública:

Accepted publickey for ubuntu from 198.51.100.25 port 53142 ssh2: ED25519 SHA256:8YpQm5B3Yc0y2qQpN5uSvrIvnL1F7AC2kX0aLrM9XvE

Saia dessa sessão e tente conectar forçando senha, sem oferecer chaves:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive "$SSH_USER@$SERVER_IP"

A resposta esperada é uma recusa, não um pedido funcional de senha:

[email protected]: Permission denied (publickey).

Por fim, teste o acesso normal, como você usará no dia a dia:

ssh -i ~/.ssh/id_ed25519_vps "$SSH_USER@$SERVER_IP"

Se quiser evitar a opção -i, crie uma entrada local em ~/.ssh/config com Host, HostName, User, IdentityFile e IdentitiesOnly yes. Confirme primeiro que os dois testes anteriores passaram. Só então encerre a sessão original que ficou aberta durante a configuração.

Troubleshooting

Permission denied (publickey)

Execute o cliente em modo detalhado para descobrir qual chave está sendo oferecida:

ssh -vvv -i ~/.ssh/id_ed25519_vps -o IdentitiesOnly=yes "$SSH_USER@$SERVER_IP"

Procure por Offering public key e Server accepts key. Se a chave não for aceita, volte pela sessão original e confira ~/.ssh/authorized_keys, a impressão digital e as permissões 700 e 600. Confirme também que o arquivo pertence ao usuário correto.

O ssh-copy-id não está disponível

No macOS, instale o utilitário pelo gerenciador de pacotes ou copie a chave por uma conexão SSH existente:

cat ~/.ssh/id_ed25519_vps.pub | ssh "$SSH_USER@$SERVER_IP" 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

Depois, conecte com ssh -i e execute ssh-keygen -lf ~/.ssh/authorized_keys na VPS. O redirecionamento acrescenta a chave e não apaga entradas existentes.

O serviço SSH não recarrega

Verifique a sintaxe e os logs sem fechar a sessão ativa:

sudo sshd -t
sudo journalctl -u ssh -u sshd -n 50 --no-pager

Se o erro começou após a criação do arquivo adicional, compare-o com o backup. Corrija a diretiva indicada e repita sudo sshd -t. Não reinicie a VPS como tentativa de correção, pois ela poderá voltar sem aceitar SSH.

A senha ainda é aceita

Consulte os valores realmente aplicados:

sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication) '

Se algum valor aparecer como yes, procure diretivas concorrentes:

sudo grep -RniE '^[[:space:]]*(PasswordAuthentication|KbdInteractiveAuthentication)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d

Corrija a precedência, valide com sshd -t, recarregue o serviço e repita o teste forçando senha.

Próximos passos

Configure ~/.ssh/config no computador para simplificar a conexão e use ssh-agent para armazenar temporariamente a passphrase. Gere uma chave separada para cada dispositivo, pois isso permite revogar um computador sem substituir todas as credenciais.

Depois, restrinja o firewall à porta SSH usada, mantenha o OpenSSH atualizado e monitore tentativas de acesso nos logs. Não troque a porta como única medida de segurança. Chaves, atualizações e controle de rede oferecem proteção mais consistente.

Se a máquina hospedar aplicações e ambientes de programação, consulte o guia de escolha de VPS para desenvolvedores para relacionar segurança, recursos e fluxo de deploy. Guarde também uma cópia criptografada da chave privada e documente como acessar o console de recuperação do provedor.