Segurança SSH: lista de verificação para proteger um VPS Linux

1. Atualize o sistema e ative as atualizações de segurança automáticas

Comece por instalar as atualizações pendentes: o apt update atualiza as listas de pacotes e o apt upgrade instala as novas versões. [1]

sudo apt update
sudo apt upgrade

No Ubuntu, o pacote unattended-upgrades instala automaticamente as atualizações de segurança; vem instalado de origem e é executado uma vez por dia. Os dois valores em /etc/apt/apt.conf.d/20auto-upgrades devem ser «1», e uma execução de teste (dry run) mostra o que o pacote instalaria. [1]

cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run -v

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

O pacote não reinicia o servidor por iniciativa própria, porque Unattended-Upgrade::Automatic-Reboot tem o valor false por predefinição; por isso, reinicie-o manualmente quando uma atualização o exigir. [1] No Debian 12, se faltar o pacote ou o ficheiro, instale o unattended-upgrades e crie o ficheiro com as duas linhas acima.

2. Crie um utilizador sudo em vez de usar o root

Faça as tarefas de administração com a sua própria conta de utilizador e o sudo, que pede a palavra-passe desse utilizador, e não a do root. Através do sudo, os membros do grupo sudo obtêm acesso root total. [2]

sudo adduser deploy
sudo adduser deploy sudo

O adduser pede uma palavra-passe e alguns dados opcionais. [2] Escolha uma palavra-passe longa: o SSH vai usar chaves, mas o sudo continua a pedi-la. Depois, teste a conta: sudo whoami deve mostrar root.

su - deploy
sudo whoami

No Debian 12, se o comando sudo não existir, instale-o primeiro como root com apt install sudo.

3. Gere uma chave ed25519 no seu computador

Crie o par de chaves no seu próprio computador, não no servidor. O Ubuntu recomenda o tipo ed25519 pelas chaves mais curtas e pelo menor custo computacional, e o ssh-keygen pede uma frase-passe (passphrase) que protege a chave privada. [3]

ssh-keygen -t ed25519

Mantenha o nome de ficheiro predefinido. A chave privada é ~/.ssh/id_ed25519; a chave pública, que é a que copia para os servidores, é ~/.ssh/id_ed25519.pub. [3]

No Windows, execute o mesmo comando no PowerShell; o par de chaves fica guardado na pasta .ssh do seu perfil de utilizador. A Microsoft desaconselha deixar a frase-passe vazia e avisa que quem obtiver a chave privada pode iniciar sessão em seu nome. [4]

ssh-keygen -t ed25519

4. Copie a chave pública para o servidor

No Linux e no macOS, o ssh-copy-id acrescenta a sua chave pública ao ~/.ssh/authorized_keys do utilizador no servidor. [3]

ssh-copy-id deploy@203.0.113.10

Já o guia da Microsoft copia as chaves com o PowerShell ou com o scp. [4] Para um servidor Linux, esta linha acrescenta a sua chave e faz com que só o seu utilizador possa escrever na pasta e no ficheiro:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

O sshd verifica estas permissões antes de aceitar um início de sessão, através da opção StrictModes, que está ativa por predefinição. [5] Depois, execute ssh deploy@203.0.113.10 num novo terminal: deve entrar sem a palavra-passe da conta. Se não conseguir, acompanhe o registo do SSH no servidor enquanto volta a tentar: [3]

sudo journalctl -fu ssh.service

5. Escreva as suas definições num ficheiro à parte

No Ubuntu, o /etc/ssh/sshd_config começa com Include /etc/ssh/sshd_config.d/*.conf e, na maioria das definições, o OpenSSH fica com o primeiro valor que lê, pelo que os ficheiros dessa pasta se sobrepõem ao ficheiro principal. [3] Os ficheiros incluídos são lidos por ordem lexicográfica e, para cada palavra-chave, prevalece o primeiro valor que o sshd obtém, [5] por isso dê ao seu ficheiro o nome 00-hardening.conf.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers deploy

Segundo o manual do sshd_config:

• PermitRootLogin no impede o root de iniciar sessão por SSH. O valor predefinido, prohibit-password, recusa palavras-passe para o root, mas continua a aceitar chaves. [5]
• PasswordAuthentication no desativa o início de sessão com palavra-passe, que é permitido por predefinição. [5]
• KbdInteractiveAuthentication no desativa o início de sessão keyboard-interactive (interativo por teclado), um método à parte que também está ativo por predefinição; o nome antigo desta opção é ChallengeResponseAuthentication. [5]
• AllowUsers deploy (opcional) só deixa iniciar sessão os utilizadores indicados. Ao contrário da maioria das palavras-chave, cada linha AllowUsers acrescenta nomes à lista. [5] Escreva o nome sem erros, senão ninguém consegue entrar.

A partir de agora, trate a conta sudo como se fosse o root: as notas do pacote openssh do Ubuntu consideram que qualquer conta a partir da qual se consiga obter privilégios de root equivale ao root perante ataques externos. [6] No Debian 12, confirme primeiro a linha Include com grep -n Include /etc/ssh/sshd_config.

6. Procure ficheiros que voltem a permitir palavras-passe

Uma vez que prevalece o primeiro valor lido, qualquer ficheiro que fique antes do seu na ordenação tem prioridade. Verifique a pasta:

ls /etc/ssh/sshd_config.d/
sudo grep -riE 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Nas imagens de cloud, o cloud-init escreve as definições SSH que gere em /etc/ssh/sshd_config.d/50-cloud-init.conf sempre que o sshd_config inclui essa pasta. [7] Se esse ficheiro tiver PasswordAuthentication yes, prevalece sobre todos os ficheiros que vêm depois dele na ordenação, e é por isso que o nome do seu começa por 00. Altere também esse valor para no, para que os ficheiros não se contradigam.

7. Teste a configuração e reinicie o SSH

Teste os ficheiros antes de reiniciar: uma definição errada pode impedir o sshd de arrancar, e o SSH pode ser a sua única forma de entrar. [3]

sudo sshd -t
sudo systemctl restart ssh.service

Corrija primeiro tudo o que o sshd -t assinalar. Depois de reiniciar, mantenha a sessão aberta e teste a partir de um segundo terminal:

ssh deploy@203.0.113.10
ssh root@203.0.113.10

O primeiro início de sessão deve funcionar e o segundo deve ser recusado. Se não conseguir entrar, desfaça a alteração na sessão que tem aberta e consulte o registo do SSH indicado no passo 4. [3]

8. Altere a porta no Ubuntu 24.04 (opcional)

No Ubuntu 24.04, o ssh.socket está à escuta na porta 22 através da ativação por socket do systemd. Um gerador converte as linhas Port do sshd_config e dos ficheiros que este inclui em definições do socket, pelo que, depois de alterar a porta, tem de recarregar o systemd e reiniciar o ssh.socket. [6]

O sshd aceita mais do que uma linha Port, [5] por isso mantenha a 22 enquanto testa a nova porta:

Port 22
Port 2222

sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Teste a nova porta a partir de um segundo terminal. Depois, apague a linha Port 22, repita os três comandos e use a porta 2222 nos passos 9 e 10.

ssh -p 2222 deploy@203.0.113.10

No Debian 12, verifique primeiro se o socket está a ser usado. Se estiver inativo, basta reiniciar o serviço para aplicar a alteração.

systemctl is-active ssh.socket
sudo systemctl restart ssh.service

9. Permita o SSH no UFW antes de o ativar

O UFW vem instalado mas desativado e, depois de ativado, recusa por predefinição o tráfego de entrada. O manual do UFW avisa que ufw enable pode cortar as ligações SSH, por isso acrescente primeiro a regra do SSH. [8]

Para o SSH, use limit em vez de allow. Uma regra limit continua a permitir ligações, mas recusa um endereço que tente abrir 6 ou mais em 30 segundos. Não acrescente as duas regras, porque o UFW aplica a primeira regra que corresponder. [8]

sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

O UFW pede confirmação quando o ativa por SSH. [8] Se mudou o SSH de porta, aplique o limite a 2222/tcp em vez da porta 22. No Debian 12, se o comando não existir, instale primeiro o UFW. Para retirar o SSH da internet pública por completo, aceda a ele apenas através de uma rede privada WireGuard. Para uma proteção mais a montante, veja a nossa lista de verificação de proteção DDoS para alojamento VPS.

10. Acrescente o Fail2ban com a jail sshd

No Ubuntu 24.04, o pacote traz o ficheiro /etc/fail2ban/jail.d/defaults-debian.conf, que ativa a jail sshd, define backend = systemd e aplica os bloqueios através do nftables. [9] O backend systemd lê o journal do systemd, pelo que a jail não precisa de um ficheiro de registo próprio. [10]

sudo apt install fail2ban
cat /etc/fail2ban/jail.d/defaults-debian.conf

O próprio jail.conf do Fail2ban bloqueia durante 10 minutos um endereço que falhe 5 vezes em 10 minutos, e pede que não edite esse ficheiro: coloque as suas alterações no jail.local. [10]

[sshd]
enabled = true
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
ignoreip = 127.0.0.1/8 ::1 198.51.100.7

Substitua 198.51.100.7 pelo seu próprio endereço fixo, ou apague-o. A jail predefinida usa port = ssh, por isso acrescente port = 2222 se mudou o SSH de porta. [10] No Debian 12, mantenha aqui backend = systemd e instale o python3-systemd, a biblioteca Python do systemd que este backend usa. [10] Depois, reinicie o Fail2ban e verifique se está a funcionar:

sudo systemctl restart fail2ban
sudo systemctl status fail2ban

11. Veja o que mais está à escuta

Cada porta aberta é mais uma porta de entrada. O relatório de portas à escuta do UFW mostra cada porta TCP à escuta e cada porta UDP aberta, o respetivo endereço (* significa todas as interfaces), o programa associado e as regras que se aplicam. [8]

sudo ufw show listening

Um serviço associado a 127.0.0.1 só está acessível a partir do próprio servidor. Desligue os serviços públicos de que não precisa com systemctl disable --now, como as notas do openssh do Ubuntu fazem para o ssh.socket. [6]

sudo systemctl disable --now SERVICE_NAME