Configurar o servidor SSH com segurança

Módulo 2: SSH e chaves · Tempo de leitura: 12 minutos

Objetivo de aprendizagem: Depois desta lição, saberá desativar o início de sessão com palavra-passe e o início de sessão de root com palavra-passe, verificar que definição está realmente em vigor e fazê-lo sem ficar bloqueado fora do servidor.

Conceitos-chave: sshd, sshd_config, sshd_config.d, conta o primeiro valor, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, segunda sessão, cloud-init, ssh.socket

Primeiro, a rede de segurança

Esta lição fecha uma porta pela qual o próprio utilizador tem de passar. Um erro de escrita pode significar que deixa de conseguir entrar. Por isso, antes de começar, confirme sempre o seguinte:

1. Duas chaves funcionam (lição 2.1) e já verificou numa nova janela que o início de sessão com chave funciona.
2. Um snapshot do seu VPS. Na WebOké cria-o no ecrã do VPS; noutros fornecedores também se chama snapshot ou imagem. Se algo correr mal, reponha-o.
3. A consola do seu fornecedor é-lhe familiar: aí entra sem SSH.
4. A sua sessão SSH atual fica aberta até ao fim. Uma sessão em curso continua a funcionar quando altera as definições ou recarrega o serviço. Teste cada alteração numa segunda janela.

Onde ficam as definições

O servidor SSH chama-se sshd. As suas definições estão em /etc/ssh/sshd_config. Em Debian e Ubuntu, no topo desse ficheiro, encontra esta linha:

Include /etc/ssh/sshd_config.d/*.conf

Todos os ficheiros com .conf na pasta sshd_config.d são, portanto, lidos antes do resto do ficheiro principal, por ordem alfabética. Isto é prático: coloca as suas próprias definições num ficheiro próprio e não mexe no ficheiro principal, para que uma atualização do pacote não afete as suas alterações.

Mas tem uma consequência que surpreende muita gente. Em sshd_config aplica-se o seguinte: para cada definição, conta o primeiro valor que o sshd encontra. As linhas posteriores com a mesma definição são ignoradas. Quem coloca PasswordAuthentication no no fim de sshd_config não se sobrepõe, portanto, a um ficheiro em sshd_config.d que diga yes.

A armadilha do cloud-init

Muitas imagens de VPS são configuradas no primeiro arranque pelo cloud-init. Consoante a forma como a imagem e a instalação estão configuradas, o cloud-init escreve um ficheiro como /etc/ssh/sshd_config.d/50-cloud-init.conf com, por exemplo, o seguinte conteúdo:

PasswordAuthentication yes

Como esse ficheiro é lido antes do ficheiro principal, o início de sessão por palavra-passe fica ativo, independentemente do que coloque em sshd_config. Por isso, não presuma: verifique.

root@web1:~# grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config:#PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

Há duas soluções limpas: alterar esse ficheiro para no, ou colocar as suas próprias definições num ficheiro que surja antes na ordem alfabética, como 00-beveiliging.conf. Um ficheiro 99-mijn.conf não funciona, porque nesse caso o cloud-init já ganhou.

As definições que importam

Crie o seu próprio ficheiro:

root@web1:~# nano /etc/ssh/sshd_config.d/00-beveiliging.conf

com este conteúdo:

# Início de sessão apenas com chave
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

O que significa cada linha?

• PasswordAuthentication no: o servidor deixa de aceitar palavras-passe. O valor predefinido do OpenSSH é yes.
• KbdInteractiveAuthentication no: "keyboard-interactive" é uma segunda forma de pedir uma palavra-passe, através do PAM. Se a deixar ativa, alguém pode ainda assim tentar uma palavra-passe, mesmo que PasswordAuthentication esteja em no. Em manuais mais antigos, esta definição chama-se ChallengeResponseAuthentication; desde o OpenSSH 8.7, esse é um nome alternativo obsoleto para a mesma coisa. O Debian já a define como no por predefinição, mas coloque-a mesmo assim: fica claro e também está correto noutros sistemas.
• PermitRootLogin prohibit-password: o root pode iniciar sessão, mas apenas com uma chave. É a predefinição desde o OpenSSH 7.0. Mais restritivo é PermitRootLogin no: o root não pode de todo entrar por SSH; inicia sessão como utilizador normal e utiliza sudo (lição 3.2). Só defina no quando tiver a certeza de que o início de sessão com esse utilizador e sudo funcionam.

Opcional, para quem quer ir mais longe:

AllowUsers anna
AuthenticationMethods publickey

AllowUsers só deixa entrar os utilizadores indicados; qualquer outro nome é recusado, mesmo que tenha uma chave válida. É útil, mas não se esqueça de si próprio, nem de acrescentar nomes quando adicionar um segundo administrador. AuthenticationMethods publickey indica numa só linha que apenas as chaves são aceites.

Testar, aplicar, verificar

Primeiro, peça ao sshd que verifique o ficheiro. Isto não inicia nem altera nada:

root@web1:~# sshd -t
root@web1:~#

Ausência de resultado significa: sem erros. Em caso de erro de escrita, verá a linha e o ficheiro. Só depois recarregue o serviço:

root@web1:~# systemctl reload ssh

Em Debian e Ubuntu, o serviço chama-se ssh; em AlmaLinux e Rocky Linux, sshd.

Em seguida, verifique que valor está realmente em vigor. sshd -T mostra a configuração completa e calculada, com todos os ficheiros Include processados:

root@web1:~# sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitrootlogin'
permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no

(without-password é o nome antigo de prohibit-password. As versões do OpenSSH anteriores à 10.1, como as do Debian 13 e do Ubuntu 24.04, ainda mostram o nome antigo; as mais recentes mostram prohibit-password. O significado é o mesmo.)

E agora o mais importante: teste numa segunda janela, mantendo a primeira aberta.

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$

Se funcionar, tente propositadamente iniciar sessão com uma palavra-passe. Isto tem de falhar:

anna@laptop:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@192.0.2.10
anna@192.0.2.10: Permission denied (publickey).

A seguir a Permission denied aparecem, entre parênteses, os métodos de início de sessão que o servidor ainda oferece. Se aparecer apenas publickey, está correto. Se também aparecer password ou keyboard-interactive, há algures outro valor em vigor: verifique novamente com sshd -T.

É precisamente essa lista que o exercício do curso também verifica, a partir do exterior. Em cada ligação, o seu cliente SSH pergunta primeiro que métodos são permitidos, com um pedido do tipo "none". O servidor responde com a lista, sem que seja tentada qualquer palavra-passe ou chave.

Ubuntu 24.04 e posterior: ssh.socket

No Ubuntu, desde a versão 22.10, quem escuta na porta 22 não é o próprio sshd, mas sim o systemd, através do ssh.socket. Só quando chega uma ligação é que o systemd inicia o serviço SSH. Para as definições desta lição, isso não faz diferença: systemctl reload ssh ou restart ssh é suficiente.

Faz diferença, sim, se alterar a porta ou o endereço de escuta (Port, ListenAddress). Desde o Ubuntu 24.04, o systemd lê esses valores de sshd_config, mas apenas depois de:

root@web1:~# systemctl daemon-reload
root@web1:~# systemctl restart ssh.socket

Se se esquecer disto, o servidor continua simplesmente a escutar na porta antiga. Pior: se primeiro configurar a firewall para uma nova porta e o SSH continuar na antiga, fica bloqueado fora do servidor. Verifique sempre com ss -tlnp | grep ssh onde o servidor está realmente a escutar (lição 5.1) e abra a nova porta na firewall antes de fechar a antiga. Se faz sentido usar outra porta, é algo que lê na lição 2.3.

Se, ainda assim, algo correr mal

Se deixar de conseguir entrar, abra a consola do seu fornecedor, inicie sessão como root (com a palavra-passe, porque a consola é um "teclado ligado ao servidor" e não SSH) e reverta o seu ficheiro:

root@web1:~# mv /etc/ssh/sshd_config.d/00-beveiliging.conf /root/
root@web1:~# systemctl reload ssh

Se nem isso resultar, reponha o snapshot. Na WebOké pode também definir uma nova palavra-passe de root no ecrã do VPS; outros fornecedores têm muitas vezes um botão semelhante ou um modo de recuperação (rescue).

Em AlmaLinux e Rocky Linux

O serviço chama-se sshd (systemctl reload sshd). Também aí existe um Include /etc/ssh/sshd_config.d/*.conf no topo e o sistema inclui ficheiros próprios nessa pasta; aplica-se a mesma regra do "conta o primeiro valor". Se alterar a porta, o SELinux também tem de permitir essa porta (semanage port -a -t ssh_port_t -p tcp 2222) e o firewalld tem de a abrir.

Resumo

• Em sshd_config conta o primeiro valor; os ficheiros em sshd_config.d são lidos primeiro. Coloque as suas próprias definições num ficheiro como 00-beveiliging.conf.
• Defina PasswordAuthentication no e também KbdInteractiveAuthentication no; root apenas com chave (prohibit-password) ou de todo não (no).
• Verifique com sshd -t antes de recarregar e com sshd -T que valor está realmente em vigor; atenção a um 50-cloud-init.conf.
• Teste numa segunda janela e mantenha a primeira sessão aberta. Conheça a consola e crie previamente um snapshot.
• No Ubuntu 24.04+, uma porta diferente exige systemctl daemon-reload e systemctl restart ssh.socket.

Questionário

Exercício

Exercício Z2.2: O início de sessão por palavra-passe está desativado. Desative o início de sessão por palavra-passe e o keyboard-interactive como indicado nesta lição e, depois, deixe o programa verificar a partir do exterior. Introduza o endereço IP ou o nome de anfitrião do seu servidor, a porta SSH (por predefinição 22) e o nome de utilizador com que inicia sessão (por exemplo anna, não root nem um nome inventado). O programa não inicia sessão: limita-se a perguntar, como qualquer cliente SSH antes de iniciar sessão, que métodos de início de sessão o seu servidor oferece para esse utilizador. O resultado correto é: apenas publickey.

Para saber mais

Os passos destes artigos aplicam-se ao ecrã do VPS da WebOké; noutros fornecedores funciona de forma semelhante.

• Proteger o seu VPS: os primeiros cinco minutos
• Deixou de ter acesso ao seu VPS: o que fazer?
• Snapshots e cópias de segurança do seu VPS
• Manual do sshd_config: https://man.openbsd.org/sshd_config
• Ubuntu: SSHd now uses socket-based activation: https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189
• VPS: do primeiro início de sessão a um servidor seguro 3.2: Desativar o início de sessão com palavra-passe e como root