A palavra-passe é o elo mais fraco de qualquer servidor exposto à Internet. Bots automatizados testam milhões de combinações por dia contra a porta 22, e basta uma credencial fraca para comprometer toda a máquina. A autenticação SSH com chaves criptográficas elimina esse risco: em vez de um segredo que se escreve (e que pode ser adivinhado ou interceptado), usa um par de chaves matemáticas em que a parte privada nunca sai do seu computador.
Neste tutorial prático vai configurar autenticação SSH baseada em chaves Ed25519 do zero, copiar a chave pública para o servidor, desativar por completo o login por palavra-passe e endurecer o serviço sshd contra ataques de força bruta. No fim terá um servidor Linux acessível apenas com a sua chave, protegido por Fail2ban e, opcionalmente, por um segundo fator TOTP. São 12 passos, demoram cerca de 20 minutos e funcionam tanto em Linux e macOS como em Windows com OpenSSH ou PuTTY.
Segundo dados da Okta de janeiro de 2025, a adoção de autenticação multifator na força de trabalho chegou a 70%, e os métodos resistentes a phishing cresceram 63% num ano. Configurar chaves SSH corretamente coloca os seus servidores nesse grupo mais seguro. Vamos a isso.
O que é a autenticação SSH e porque usar chaves
O SSH (Secure Shell) é o protocolo padrão para administração remota de servidores. Cifra todo o tráfego entre o cliente e o servidor, protegendo comandos, ficheiros e credenciais de quem possa estar a observar a rede. O protocolo base está definido no RFC 4253 e a implementação dominante é o OpenSSH, presente em praticamente todas as distribuições Linux, no macOS e, desde 2018, no próprio Windows.
Existem duas formas principais de provar a sua identidade ao servidor: por palavra-passe ou por chave pública. A autenticação por palavra-passe envia um segredo que o servidor verifica contra a base de dados de utilizadores. A autenticação SSH por chave usa criptografia assimétrica: gera um par formado por uma chave privada (que guarda em segredo) e uma chave pública (que coloca no servidor). O servidor lança um desafio que só pode ser resolvido por quem possui a chave privada, e essa chave nunca é transmitida pela rede.
A diferença de segurança é enorme. Uma palavra-passe de 12 caracteres tem entropia limitada e pode ser alvo de força bruta ou de phishing. Uma chave Ed25519 oferece o equivalente a cerca de 128 bits de segurança, impossível de adivinhar com a tecnologia atual. A tabela seguinte resume porque é que a autenticação SSH por chave venceu.
| Critério | Palavra-passe | Chave SSH (Ed25519) |
|---|---|---|
| Resistência a força bruta | Baixa (depende do comprimento) | Praticamente total (~128 bits) |
| Vulnerável a phishing | Sim | Não (a chave privada nunca sai) |
| Transmitida pela rede | Sim (cifrada no túnel) | Nunca |
| Reutilização entre serviços | Comum e perigosa | Cada par é único |
| Login automatizado (scripts, CI) | Difícil e inseguro | Nativo e seguro |
| Pode ser protegida por frase-secreta | Não aplicável | Sim (cifra a chave privada) |
Há ainda uma vantagem operacional: pode autorizar várias chaves no mesmo servidor e revogar uma sem afetar as outras. Isto facilita gerir acessos de vários administradores ou pipelines de automação sem partilhar segredos. Se quiser aprofundar como a cifragem em trânsito protege estas ligações, veja o nosso artigo sobre HTTPS e TLS, que partilha os mesmos princípios de criptografia assimétrica.
Pré-requisitos e versões necessárias
Antes de começar, confirme que tem o software certo dos dois lados da ligação. O cliente é a máquina onde está sentado (o seu portátil), e o servidor é a máquina remota a que se quer ligar. Os passos foram testados com as versões abaixo, mas qualquer versão recente do OpenSSH funciona de forma equivalente.
| Componente | Versão recomendada | Onde corre |
|---|---|---|
| OpenSSH (cliente e servidor) | 9.0 ou superior | Cliente e servidor |
| Linux (servidor) | Ubuntu 24.04 LTS / Debian 12 | Servidor |
| macOS | 14 Sonoma ou superior | Cliente |
| Windows | 10 (1809+) ou 11, com OpenSSH | Cliente |
| PuTTY (alternativa Windows) | 0.81 ou superior | Cliente |
| Fail2ban | 1.0 ou superior | Servidor |
| libpam-google-authenticator | Última versão dos repositórios | Servidor (opcional, 2FA) |
Precisa também de: acesso a um servidor com privilégios sudo (uma VPS, uma Raspberry Pi ou uma máquina virtual servem), o endereço IP ou nome de domínio desse servidor, e um terminal no cliente. Recomenda-se vivamente manter uma segunda sessão SSH aberta enquanto endurece a configuração, para não ficar trancado de fora caso algo corra mal. Vamos referir este conselho mais à frente.
Passo 1: Verificar a instalação do OpenSSH
Comece por confirmar que o cliente OpenSSH está instalado e ver a versão. No terminal do seu computador (Linux, macOS ou PowerShell no Windows), execute:
ssh -VA resposta deverá ser semelhante a esta:
OpenSSH_9.6p1, OpenSSL 3.0.13 30 Jan 2024Se receber um erro a indicar que o comando não foi encontrado no Windows, instale o cliente abrindo o PowerShell como administrador e correndo Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0. Em Linux, instale com sudo apt install openssh-client (Debian/Ubuntu) ou sudo dnf install openssh-clients (Fedora). No servidor, o serviço chama-se openssh-server; confirme que está ativo com sudo systemctl status ssh.
Passo 2: Escolher o algoritmo de chave certo
O OpenSSH suporta vários algoritmos para o par de chaves. A escolha afeta segurança, velocidade e compatibilidade. Em 2026, a recomendação clara para máquinas modernas é Ed25519, uma curva elíptica (EdDSA) rápida, com chaves pequenas e resistente a vários ataques de implementação. Reserve o RSA apenas para sistemas antigos que ainda não suportem Ed25519, e nesse caso use no mínimo 4096 bits.
| Algoritmo | Tamanho da chave | Segurança aproximada | Recomendação 2026 |
|---|---|---|---|
| Ed25519 | 256 bits | ~128 bits | Preferido para tudo |
| ECDSA (nistp256) | 256 bits | ~128 bits | Evitar (curvas NIST) |
| RSA 4096 | 4096 bits | ~128 bits | Só para compatibilidade |
| RSA 2048 | 2048 bits | ~112 bits | Desaconselhado |
| DSA | 1024 bits | Fraca | Removido do OpenSSH |
| Ed25519-sk (FIDO2) | 256 bits + hardware | ~128 bits + posse física | Ideal com chave física |
O sufixo -sk (security key) liga a chave a um dispositivo físico FIDO2, como uma YubiKey, exigindo a presença do token para cada autenticação. É a forma mais resistente a phishing de fazer SSH, e voltaremos a ela nas dicas avançadas. Por agora, vamos com Ed25519 normal.
Passo 3: Gerar o par de chaves com ssh-keygen
Chegou o momento central. A ferramenta ssh-keygen cria o par de chaves. Execute no cliente:
ssh-keygen -t ed25519 -a 100 -C "sam@portatil-2026"O que significa cada opção: -t ed25519 define o tipo de chave; -a 100 aplica 100 rondas de derivação à frase-secreta (KDF), tornando ataques offline à chave privada muito mais lentos; -C adiciona um comentário que ajuda a identificar a chave mais tarde. Use um comentário descritivo, como o utilizador e a máquina de origem.
O programa vai fazer duas perguntas. A primeira é o caminho do ficheiro; aceite o padrão pressionando Enter. A segunda é a frase-secreta (passphrase), que cifra a chave privada no disco. Defina sempre uma frase-secreta forte. Se a sua chave privada for copiada por alguém, a frase-secreta é a última linha de defesa.
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/sam/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sam/.ssh/id_ed25519
Your public key has been saved in /home/sam/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:9zK2c... sam@portatil-2026Pronto. Acabou de criar dois ficheiros: a chave privada e a chave pública. Nunca partilhe a primeira. A documentação completa das opções está no manual oficial do ssh-keygen do projeto OpenBSD.
Passo 4: Compreender os ficheiros de chave
Antes de avançar, vale a pena perceber o que tem na pasta ~/.ssh. Liste o conteúdo:
ls -la ~/.ssh-rw------- 1 sam sam 464 jun 11 10:22 id_ed25519
-rw-r--r-- 1 sam sam 100 jun 11 10:22 id_ed25519.pub
-rw------- 1 sam sam 978 jun 11 10:25 known_hostsO ficheiro id_ed25519 é a chave privada. Repare nas permissões -rw------- (600): apenas o dono pode ler. O OpenSSH recusa-se a usar chaves privadas com permissões demasiado abertas, por motivos de segurança. O ficheiro id_ed25519.pub é a chave pública, em texto, que pode partilhar livremente. O seu conteúdo é uma única linha:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH8k...J2qd sam@portatil-2026Do lado do servidor, esta linha será adicionada ao ficheiro ~/.ssh/authorized_keys da conta a que se quer ligar. O servidor consulta esse ficheiro para decidir quem pode entrar. Já o ficheiro known_hosts, no cliente, guarda as impressões digitais dos servidores a que já se ligou, e é o que o protege contra ataques de homem-no-meio: se a chave de um servidor mudar inesperadamente, o SSH avisa-o.
Passo 5: Copiar a chave pública para o servidor
Agora tem de colocar a chave pública no servidor. A forma mais simples é a ferramenta ssh-copy-id, disponível em Linux e macOS. Esta primeira ligação ainda usa a palavra-passe da conta (que vamos desativar mais à frente):
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]Substitua sam pelo nome de utilizador no servidor e 192.0.2.50 pelo IP ou domínio. A ferramenta cria a pasta ~/.ssh no servidor com as permissões corretas, adiciona a sua chave ao authorized_keys e ajusta as permissões. No fim verá uma mensagem a confirmar o número de chaves adicionadas.
Se estiver no Windows sem ssh-copy-id, ou preferir o método manual, copie a chave com um comando único. No PowerShell:
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"Em Linux ou macOS, o equivalente manual é cat ~/.ssh/id_ed25519.pub | ssh [email protected] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys". Seja qual for o método, o objetivo é o mesmo: a sua linha de chave pública fica no authorized_keys do servidor.
Passo 6: Testar o login e usar o ssh-agent
Teste imediatamente a nova ligação por chave, ainda sem desativar nada:
ssh [email protected]Se definiu uma frase-secreta, o sistema vai pedi-la. Se entrou sem que lhe pedissem a palavra-passe da conta, a autenticação por chave está a funcionar. Escrever a frase-secreta a cada ligação é incómodo, e é aí que entra o ssh-agent: um processo que guarda a chave desbloqueada em memória durante a sessão. Inicie-o e adicione a chave:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519No macOS, adicione --apple-use-keychain para guardar a frase-secreta no porta-chaves do sistema. No Windows, o agente corre como serviço; ative-o com Start-Service ssh-agent e Set-Service ssh-agent -StartupType Automatic no PowerShell de administrador, e depois ssh-add. A partir daqui, as ligações usam a chave já desbloqueada, sem voltar a pedir a frase-secreta nesta sessão.
Passo 7: Endurecer o sshd_config no servidor
Este é o passo mais importante para a segurança. Vamos editar a configuração do servidor SSH para desativar a autenticação por palavra-passe e o login direto do utilizador root. Mantenha a sua sessão atual aberta e abra uma segunda ligação para testar, de modo a recuperar caso bloqueie o acesso. Edite o ficheiro no servidor:
sudo nano /etc/ssh/sshd_configLocalize e altere (ou acrescente) as seguintes diretivas. Remova o cardinal # do início caso a linha esteja comentada:
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
AllowUsers samA tabela seguinte explica o efeito de cada diretiva, todas documentadas no manual do sshd_config.
| Diretiva | Valor | Efeito |
|---|---|---|
| PubkeyAuthentication | yes | Permite login por chave |
| PasswordAuthentication | no | Desativa palavras-passe (chave obrigatória) |
| PermitRootLogin | no | Impede login direto como root |
| MaxAuthTries | 3 | Corta a ligação após 3 tentativas |
| LoginGraceTime | 30 | Fecha sessões não autenticadas em 30s |
| AllowUsers | sam | Só estes utilizadores podem entrar |
| PermitEmptyPasswords | no | Bloqueia contas sem palavra-passe |
Guarde o ficheiro. Antes de reiniciar o serviço, valide a sintaxe com sudo sshd -t; se não devolver nada, está correto. Depois aplique com sudo systemctl restart ssh. Agora abra uma nova janela e teste o login. Só feche a sessão original depois de confirmar que consegue entrar com a chave.
Passo 8: Mudar a porta e configurar a firewall
Mudar a porta padrão (22) para um número alto não é segurança real, mas reduz drasticamente o ruído dos bots automatizados que só varrem a 22. Combinada com uma firewall, é uma camada útil. Defina a nova porta no sshd_config acrescentando, por exemplo, Port 2222. De seguida, configure a firewall UFW (comum em Ubuntu) para permitir essa porta antes de reiniciar o serviço:
sudo ufw allow 2222/tcp
sudo ufw enable
sudo ufw statusO comando ufw status deve listar a porta 2222 como permitida. Reinicie o SSH e ligue-se indicando a porta com ssh -p 2222 [email protected]. Atenção: se não abrir a porta na firewall antes de reiniciar, fica trancado de fora. Por isso mantemos sempre uma sessão de reserva aberta. Não se esqueça também de atualizar regras na firewall do seu fornecedor de cloud, se existir.
Para uma defesa de rede mais ampla em torno do servidor, vale a pena conhecer as opções de VPN. O nosso artigo WireGuard vs OpenVPN compara duas formas de só expor o SSH dentro de um túnel privado, o que é ainda mais seguro do que mudar a porta.
Passo 9: Bloquear força bruta com Fail2ban
Mesmo com palavras-passe desativadas, os bots continuam a tentar ligar-se. O Fail2ban monitoriza os registos e bane temporariamente os endereços IP com demasiadas tentativas falhadas. Instale-o no servidor:
sudo apt install fail2ban -yCrie um ficheiro de configuração local (nunca edite o jail.conf diretamente, pois é substituído nas atualizações):
sudo nano /etc/fail2ban/jail.local[sshd]
enabled = true
port = 2222
maxretry = 3
findtime = 600
bantime = 3600
backend = systemdEsta configuração bane um IP por uma hora (bantime = 3600) após 3 tentativas falhadas (maxretry) em 10 minutos (findtime). Ajuste a port se mudou a porta no passo anterior. Ative e reinicie o serviço, e verifique o estado:
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshdO resultado mostra quantos IP estão banidos e o total de tentativas detetadas. Pode consultar a documentação oficial do projeto em fail2ban.org. Esta camada não substitui a autenticação por chave, mas reduz o tráfego malicioso e protege contra falhas de configuração futuras.
Passo 10: Simplificar ligações com o ficheiro ~/.ssh/config
Escrever ssh -p 2222 [email protected] de cada vez é cansativo. O ficheiro de configuração do cliente permite definir atalhos. Crie ou edite ~/.ssh/config no seu computador:
Host servidor-web
HostName 192.0.2.50
User sam
Port 2222
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
AddKeysToAgent yesA partir de agora basta escrever ssh servidor-web para se ligar com todas as opções definidas. A diretiva IdentitiesOnly yes garante que o cliente só oferece a chave indicada, evitando o erro comum de o servidor recusar a ligação por excesso de tentativas quando tem muitas chaves no agente. Pode definir quantos blocos Host quiser, um por servidor.
Verifique as permissões do ficheiro com chmod 600 ~/.ssh/config. O OpenSSH ignora ficheiros de configuração com permissões demasiado abertas, tal como faz com as chaves privadas.
Passo 11: SSH no Windows com PuTTY e OpenSSH
O termo PuTTY tem cerca de 2900 pesquisas mensais em Portugal, sinal de que muitos utilizadores Windows ainda recorrem a este cliente clássico. Embora o Windows 10 e 11 já incluam OpenSSH nativo (que funciona igual aos comandos deste tutorial), o PuTTY continua popular pela sua interface gráfica. A diferença está no formato das chaves.
Gerar e converter chaves com PuTTYgen
O PuTTY usa o seu próprio formato (.ppk). Para gerar uma chave, abra o PuTTYgen, escolha “EdDSA” com a curva Ed25519, clique em “Generate” e mexa o rato para gerar entropia. Defina uma frase-secreta no campo “Key passphrase” e guarde a chave privada como ficheiro .ppk. A chave pública no formato OpenSSH aparece na caixa de texto superior, pronta a colar no authorized_keys do servidor.
Se já tem uma chave Ed25519 gerada com ssh-keygen, importe o ficheiro id_ed25519 no PuTTYgen através de “Conversions > Import key” e exporte-a como .ppk. No cliente PuTTY, indique o ficheiro .ppk em “Connection > SSH > Auth > Credentials”. O agente equivalente ao ssh-agent chama-se Pageant e guarda a chave desbloqueada para todas as sessões PuTTY.
Quando preferir o OpenSSH nativo
Para quem trabalha com automação ou prefere a linha de comandos, o OpenSSH nativo do Windows é a opção mais simples: usa exatamente os mesmos comandos e ficheiros (~/.ssh/config, id_ed25519) deste tutorial, e integra-se com o Windows Terminal e o VS Code. Para a maioria dos casos novos em 2026, recomenda-se o OpenSSH em vez do PuTTY.
Passo 12: Adicionar 2FA com TOTP ao SSH (opcional)
Para servidores de alto valor, pode combinar a chave SSH com um segundo fator TOTP, exigindo um código de seis dígitos do Google Authenticator além da chave. Isto cria autenticação de dois fatores real ao nível do SSH. Instale o módulo PAM no servidor:
sudo apt install libpam-google-authenticator -y
google-authenticatorO assistente faz várias perguntas (responda “y” para tokens baseados em tempo) e mostra um código QR para ler na aplicação autenticadora. Guarde os códigos de recuperação num local seguro. De seguida, no sshd_config, defina KbdInteractiveAuthentication yes e adicione AuthenticationMethods publickey,keyboard-interactive, que obriga a apresentar a chave e o código. Por fim, edite /etc/pam.d/sshd e acrescente a linha auth required pam_google_authenticator.so.
Reinicie o serviço e teste numa segunda sessão. Para perceber a fundo como funciona o TOTP e o padrão RFC 6238 por trás destes códigos, leia o nosso guia detalhado de autenticação de dois fatores em Node.js. Os princípios do segredo partilhado e da janela de tempo são exatamente os mesmos.
Como funciona o handshake SSH por dentro
Perceber o que acontece nos bastidores ajuda a diagnosticar problemas e a confiar na segurança da autenticação SSH. Quando escreve ssh servidor-web, o cliente e o servidor passam por três fases bem definidas antes de lhe darem uma shell.
Na primeira fase, a negociação do protocolo, ambos os lados anunciam as versões e os algoritmos que suportam (cifras, trocas de chave, MAC). É aqui que diretivas como PubkeyAcceptedAlgorithms entram em ação. Se o cliente e o servidor não tiverem nenhum algoritmo em comum, a ligação falha logo nesta etapa, com a mensagem de “no mutual signature algorithm” que aparece na tabela de resolução de problemas.
Na segunda fase, a troca de chaves, o cliente e o servidor usam um algoritmo Diffie-Hellman de curva elíptica para acordar uma chave de sessão secreta sem nunca a transmitir. É também aqui que o servidor apresenta a sua chave de máquina (host key), que o cliente compara com o known_hosts. Se for a primeira ligação, o SSH mostra-lhe a impressão digital e pergunta se confia nela. Confirmar esta impressão por um canal seguro é o que impede ataques de homem-no-meio. A partir deste ponto, todo o tráfego segue cifrado.
Só na terceira fase, a autenticação do utilizador, é que entra a sua chave. O servidor envia um desafio aleatório; o cliente assina-o com a chave privada (desbloqueada pela frase-secreta ou pelo agente) e devolve a assinatura. O servidor verifica-a com a chave pública guardada no authorized_keys. Se a assinatura for válida, está autenticado. Repare que a chave privada nunca é enviada: apenas uma assinatura que prova a sua posse. É por isso que a autenticação SSH por chave resiste a interceção, ao contrário da palavra-passe.
Este modelo de prova por desafio é o mesmo princípio das assinaturas digitais usadas em certificados e em blockchain. Para uma explicação mais profunda do conceito de assinar e verificar com pares de chaves, o nosso pilar de cibersegurança reúne os fundamentos que sustentam o SSH, o TLS e muito mais.
Criar um utilizador dedicado com sudo
Trabalhar sempre como root é um risco desnecessário, e desativámos o login direto de root no passo 7. Antes disso, convém criar um utilizador normal com privilégios sudo e colocar a sua chave nessa conta. Se ainda estiver a usar a conta root, crie o utilizador no servidor:
sudo adduser sam
sudo usermod -aG sudo samO comando adduser cria a conta e a pasta pessoal, pedindo uma palavra-passe (necessária apenas para o sudo, já que o login remoto passará a usar a chave). O usermod -aG sudo adiciona o utilizador ao grupo sudo, dando-lhe poder administrativo controlado. Em distribuições como o CentOS ou o Fedora, o grupo chama-se wheel em vez de sudo.
Depois, copie a sua chave pública para esta nova conta (não para a do root) usando o ssh-copy-id [email protected] do passo 5. Confirme que consegue entrar como sam e executar sudo whoami, que deve devolver root após pedir a palavra-passe da conta. Só depois de validar este fluxo é que deve desativar o login de root e a autenticação por palavra-passe.
Esta separação segue o princípio do menor privilégio: o utilizador normal trata das tarefas do dia a dia e só eleva privilégios quando necessário, deixando um rasto de auditoria nos registos do sudo. É uma defesa simples mas eficaz, alinhada com as recomendações de gestão de contas que abordamos no guia de segurança de palavras-passe.
Gerir várias chaves e rotação de credenciais
À medida que acumula servidores e serviços, vai querer mais do que uma única chave. A boa prática é segmentar: uma chave para acessos pessoais, outra para automação, outra para clientes ou projetos específicos. Se uma for comprometida, revoga apenas essa, sem afetar o resto. Gere cada par com um nome distinto:
ssh-keygen -t ed25519 -f ~/.ssh/id_trabalho -C "sam@trabalho"
ssh-keygen -t ed25519 -f ~/.ssh/id_pessoal -C "sam@pessoal"Depois associe cada chave ao servidor certo no ~/.ssh/config, indicando o IdentityFile correspondente em cada bloco Host. Assim, o cliente apresenta sempre a chave certa, sem tentativas falhadas. Para listar as impressões digitais de todas as suas chaves de uma vez, use:
for k in ~/.ssh/id_*; do ssh-keygen -lf "$k"; doneA rotação de chaves é tão importante quanto a rotação de palavras-passe. Defina um calendário (por exemplo, anual) para gerar pares novos, distribuí-los e remover os antigos do authorized_keys dos servidores. Quando um colaborador sai da equipa, a primeira ação deve ser apagar a sua chave pública de todas as máquinas. Uma auditoria periódica ao conteúdo do authorized_keys evita que chaves esquecidas se tornem portas dos fundos.
Para ver de imediato quem tem acesso a um servidor, basta inspecionar o ficheiro: cat ~/.ssh/authorized_keys lista cada chave autorizada, com o comentário que adicionou ao gerar (por isso é útil usar comentários descritivos). Em ambientes maiores, ferramentas de gestão de configuração como o Ansible automatizam a distribuição e remoção de chaves em dezenas de máquinas a partir de uma fonte única de verdade, eliminando o erro humano.
Erros comuns e como evitá-los
Estes são os tropeções mais frequentes ao configurar autenticação SSH por chave. Conhecê-los poupa horas de frustração.
- Ficar trancado de fora. Desativar a palavra-passe ou mudar a porta sem testar primeiro numa segunda sessão é o erro mais perigoso. Mantenha sempre uma ligação ativa enquanto altera o
sshd_confige valide comsudo sshd -t. - Permissões erradas. O OpenSSH recusa chaves e ficheiros com permissões demasiado abertas. A pasta
~/.sshdeve ser 700, a chave privada e oauthorized_keysdevem ser 600. Usechmodpara corrigir. - Confundir chave pública e privada. Só a chave pública (
.pub) vai para o servidor. Enviar a chave privada compromete-a por completo e obriga a gerar um par novo. - Não usar frase-secreta. Uma chave privada sem frase-secreta é como uma palavra-passe escrita num papel: quem copiar o ficheiro entra de imediato. Use sempre uma frase forte.
- Esquecer a firewall do fornecedor. Abrir a porta no UFW não basta se o painel da cloud (AWS, Hetzner, OVH) tiver as suas próprias regras. Atualize ambos.
- Copiar a chave com quebras de linha. Ao colar manualmente a chave pública, certifique-se de que fica numa única linha no
authorized_keys. Quebras de linha invalidam-na.
Resolução de problemas de autenticação SSH
Quando uma ligação falha, o primeiro passo é ligar com saída detalhada usando ssh -vvv [email protected]. As mensagens revelam exatamente onde a autenticação parou. A tabela abaixo reúne os problemas mais comuns e a respetiva solução.
| Sintoma / mensagem | Causa provável | Solução |
|---|---|---|
| Permission denied (publickey) | Chave não está no authorized_keys ou ficheiro errado | Verifique o conteúdo e use -i para indicar a chave |
| Connection refused | Serviço SSH parado ou porta errada | Confirme systemctl status ssh e a porta |
| Connection timed out | Firewall a bloquear ou IP errado | Verifique UFW e regras da cloud |
| Bad permissions on private key | Permissões abertas demais | chmod 600 ~/.ssh/id_ed25519 |
| Too many authentication failures | Agente a oferecer muitas chaves | Adicione IdentitiesOnly yes ao config |
| Host key verification failed | Chave do servidor mudou | Remova a linha antiga do known_hosts |
| Agent admitted failure to sign | Chave não carregada no agente | Corra ssh-add ~/.ssh/id_ed25519 |
| no mutual signature algorithm | Algoritmo desativado no servidor | Atualize o servidor ou ajuste PubkeyAcceptedAlgorithms |
Se for mesmo bloqueado, a maioria dos fornecedores de cloud oferece uma consola web (VNC ou serial) que dá acesso à máquina sem SSH. Use-a para repor o sshd_config ou reativar temporariamente a palavra-passe. Manter um snapshot recente do servidor também ajuda a recuperar de configurações irreversíveis.
Dicas avançadas para autenticação SSH
Saltar para servidores internos com ProxyJump
Para chegar a máquinas numa rede privada através de um servidor de salto (bastion), use o ProxyJump no ~/.ssh/config: ProxyJump bastion numa entrada de host faz o SSH encaminhar a ligação automaticamente. É mais seguro do que o antigo encaminhamento de agente (ForwardAgent), que deve evitar por expor a sua chave a servidores intermédios.
Chaves de hardware FIDO2 (sk-ed25519)
A forma mais resistente a phishing de fazer SSH é ligar a chave a um token físico. Gere-a com ssh-keygen -t ed25519-sk com uma YubiKey ligada. A chave privada fica protegida pelo hardware e cada autenticação exige tocar no dispositivo, tornando o roubo remoto impossível. Os dados da Okta mostram que os autenticadores resistentes a phishing cresceram 63% no último ano, e esta é a aplicação dessa tendência ao SSH.
Certificados SSH para escala
Em organizações com dezenas de servidores, gerir o authorized_keys de cada máquina não escala. Os certificados SSH permitem que uma autoridade certificadora (CA) assine chaves com validade limitada, eliminando a distribuição manual. Combine-os com o princípio de rotação regular: gere chaves novas periodicamente e revogue as antigas, à semelhança das boas práticas de gestão de credenciais.
Boas práticas de segurança SSH em 2026
Reunindo tudo, eis a lista de verificação que deve seguir em qualquer servidor de produção. Trate a chave privada como um segredo crítico e nunca a copie para máquinas em que não confia plenamente.
- Use Ed25519 e proteja sempre a chave privada com uma frase-secreta forte.
- Desative por completo a autenticação por palavra-passe (
PasswordAuthentication no). - Proíba o login direto como root (
PermitRootLogin no) e usesudo. - Limite quem pode entrar com
AllowUsersouAllowGroups. - Instale Fail2ban e mantenha o OpenSSH atualizado para corrigir vulnerabilidades.
- Para acessos sensíveis, adicione 2FA TOTP ou uma chave de hardware FIDO2.
- Faça auditorias regulares ao
authorized_keyse remova chaves obsoletas. - Considere expor o SSH apenas dentro de uma VPN, em vez de o deixar na Internet aberta.
A segurança de um servidor depende sempre da camada mais fraca. Combinar chaves fortes, um sshd endurecido e monitorização de tentativas falhadas coloca-o muito à frente da grande maioria das máquinas expostas. Para o contexto mais amplo de como os atacantes entram nos sistemas, vale a pena rever como ocorrem as violações de dados e quanto a má gestão de credenciais contribui para elas.
Leitura Relacionada
- Cibersegurança: o nosso pilar de segurança online
- Segurança de Palavras-passe: Guia Prático
- Autenticação de Dois Fatores em Node.js: 12 Passos
- HTTPS e TLS: O que o Cadeado Protege
- WireGuard vs OpenVPN: Comparação de Desempenho
- Violações de Dados: Como Acontecem e Como se Proteger
Perguntas Frequentes sobre autenticação SSH
Posso usar a mesma chave SSH em vários servidores?
Sim. A mesma chave pública pode ser adicionada ao authorized_keys de quantos servidores quiser, e a chave privada fica sempre no seu computador. Muitos administradores preferem, no entanto, chaves diferentes por contexto (trabalho, pessoal, automação) para limitar o impacto caso uma seja comprometida e poder revogá-la isoladamente.
O que faço se perder a chave privada?
Sem a chave privada não consegue entrar nos servidores que a usavam. Se ainda tiver acesso por outra via (consola da cloud, segunda chave), remova a chave pública perdida do authorized_keys e adicione uma nova. Por isso é boa prática autorizar uma segunda chave de recuperação guardada em local seguro, ou manter acesso à consola web do fornecedor.
Ed25519 ou RSA: qual devo escolher?
Escolha Ed25519 em todos os sistemas modernos. É mais rápido, gera chaves mais pequenas e é resistente a várias falhas de implementação. Use RSA 4096 apenas se precisar de se ligar a equipamento antigo que não suporte Ed25519, como alguns routers ou sistemas embebidos mais velhos.
É seguro desativar totalmente a palavra-passe?
Sim, é precisamente a recomendação. Com PasswordAuthentication no, os ataques de força bruta deixam de ter qualquer hipótese, pois nenhuma palavra-passe é aceite. O único requisito é garantir que tem a chave configurada e testada antes de desativar, e idealmente uma chave de recuperação ou acesso à consola.
Mudar a porta 22 melhora mesmo a segurança?
Mudar a porta não impede um atacante determinado, que faz uma análise de portas em segundos. O benefício real é reduzir o volume de tentativas automáticas e o ruído nos registos, já que a maioria dos bots só varre a porta 22. Trate-a como uma camada complementar, nunca como substituta da autenticação por chave.
Como adiciono autenticação SSH a pipelines de CI/CD?
Gere uma chave dedicada, sem frase-secreta (ou com uma gerida pelo sistema de segredos), e adicione a chave pública ao servidor de destino. Guarde a chave privada nas variáveis de segredo do seu sistema de CI (GitHub Actions, GitLab CI), nunca no repositório. Restrinja essa chave com a opção command= no authorized_keys para que só possa executar a ação pretendida.
O Windows precisa do PuTTY para fazer SSH?
Não. Desde o Windows 10 versão 1809, o cliente OpenSSH vem incluído e usa os mesmos comandos deste tutorial. O PuTTY continua a ser uma opção válida e popular pela interface gráfica e pelo Pageant, mas para novos projetos o OpenSSH nativo costuma ser mais simples e integra-se melhor com ferramentas como o VS Code e o Windows Terminal.
Como faço uma cópia de segurança das minhas chaves SSH?
Copie a pasta ~/.ssh para um suporte cifrado e offline, como uma pen protegida com VeraCrypt ou um gestor de palavras-passe que aceite ficheiros. Nunca guarde a chave privada num serviço de cloud sem cifragem adicional, nem a envie por email ou mensagem. Como a chave já está protegida por uma frase-secreta, mesmo que o suporte se perca, um atacante ainda teria de a quebrar. Ainda assim, trate o backup com o mesmo cuidado que daria a uma chave de casa.
O SSH é seguro contra computação quântica?
As chaves Ed25519 e RSA atuais não são resistentes a um computador quântico de grande escala, que ainda não existe mas é uma preocupação a longo prazo. O OpenSSH já introduziu trocas de chave híbridas pós-quânticas para proteger o segredo da sessão contra ataques de “guardar agora, decifrar depois”. Para administração normal em 2026, as chaves Ed25519 continuam perfeitamente seguras; vale a pena acompanhar a evolução dos algoritmos pós-quânticos à medida que o NIST os padroniza.
Com estes 12 passos tem um servidor com autenticação SSH por chave, palavra-passe desativada, firewall configurada e proteção contra força bruta. É a base de qualquer infraestrutura segura. Consulte sempre a documentação oficial do OpenSSH e o glossário do NIST sobre SSH para se manter atualizado sobre novas diretivas e algoritmos recomendados.
