Como reforçar a configuração do servidor SSH
Última atualização:
O ficheiro sshd_config é toda a postura de segurança do seu servidor SSH num único ficheiro de texto — e na maioria dos sistemas chega num estado otimizado para compatibilidade, não para segurança. O início de sessão por palavra-passe vem ligado por omissão, o root pode entrar desde que use uma chave, as sessões inativas nunca expiram e os algoritmos que o seu servidor oferece são os que a versão do OpenSSH instalada há anos decidiu. Reforçá-lo não é copiar uma lista de 2021: os algoritmos são retirados, os valores por omissão mudam e uma configuração exemplar há cinco anos pode ser fraca hoje. Este artigo explica o que cada mudança realmente faz, por que a ordem das suas decisões importa e como testar uma nova configuração sem ficar de fora. Pode auditar o seu próprio ficheiro linha a linha no auditor de configuração do servidor SSH, que o compara com uma base de referência datada de 2026-11-13, tudo no seu navegador.
Os valores por omissão são um ponto de partida, não uma postura de segurança
O OpenSSH chega com valores por omissão escolhidos para que uma instalação nova funcione para o maior número de pessoas possível — e essa é exatamente a razão por que não são uma postura de segurança. Os valores atuais, conforme documenta a página do manual do sshd_config, incluem PasswordAuthentication yes, PermitRootLogin prohibit-password, MaxAuthTries 6, LoginGraceTime 120 segundos e ClientAliveInterval 0, o que significa que as sessões inativas nunca são terminadas. Nenhum deles é um erro: cada um é uma decisão deliberada de compatibilidade, e cada um é um achado numa auditoria de reforço.
A consequência prática é que um servidor que ninguém reforçou continua alcançável por adivinhação de palavras-passe, continua a aceitar inícios de sessão de root com uma chave roubada e continua a deixar sessões abandonadas abertas indefinidamente. Os valores por omissão também mudam com o tempo — o que o OpenSSH 10.6 traz não é o que o OpenSSH 7 trazia — por isso «nunca mudei nada» não é uma afirmação neutra. Significa que a sua postura de segurança é a que a versão que lhe calhou instalar decidiu, e a única forma de saber é ler o ficheiro. Esse é o primeiro trabalho de uma auditoria: tornar visíveis os valores por omissão invisíveis, porque uma diretiva que não aparece no ficheiro continua em vigor.
Desligar as palavras-passe vale mais do que mudar a porta, sempre
A mudança mais eficaz no sshd_config é PasswordAuthentication no combinado com PubkeyAuthentication yes: a partir desse momento, nenhuma palavra-passe — adivinhada, divulgada ou pescada por phishing — pode abrir uma sessão, porque o daemon deixa de aceitar esse tipo de prova. A autenticação por chave muda o ataque de «adivinhar um segredo que um humano escolheu» para «roubar um ficheiro de chave privada que nunca atravessa a rede», e é por isso que todas as bases de reforço, incluindo a da Mozilla, começam aqui. Se ficar com uma só coisa deste artigo, que seja esta: gere um par de chaves (veja o conjunto de chaves SSH e o artigo chaves SSH explicadas), instale a chave pública, verifique que consegue entrar com ela e só depois desligue as palavras-passe.
Mudar a porta de 22 para outra mais obscura, pelo contrário, não é reforçar: é obscuridade. Reduz o ruído nos seus registos, porque a maioria dos scanners da Internet só bate à porta 22, mas não detém nenhum atacante que se dê ao trabalho de varrer: um varrimento de portas encontra o daemon em segundos, e o daemon por trás dele é exatamente tão forte como a sua configuração. O auditor trata por isso uma porta diferente de 22 apenas como informação, nunca como uma melhoria pontuada. Há uma armadilha que vale a pena conhecer antes de virar o interruptor: em sistemas que usam PAM, PasswordAuthentication no por si só não basta — a autenticação por teclado interativo pode continuar a deixar o PAM aceitar uma palavra-passe, por isso a pilha PAM em /etc/pam.d/sshd também tem de recusar palavras-passe. As diretrizes da Mozilla dizem-no explicitamente, e é a metade da mudança que mais se esquece.
Início de sessão de root: o que o prohibit-password realmente permite
O PermitRootLogin tem quatro valores, e a diferença entre eles é a diferença entre ter um rasto de auditoria ou não ter. O valor por omissão, prohibit-password, permite que o root inicie sessão — apenas não com palavra-passe. Uma chave de root roubada entra na mesma sem obstáculos, e uma vez que a sessão é root, nada nos registos distingue um administrador de outro. O perfil Modern da Mozilla fixa-o em No, e essa é a resposta reforçada: o root nunca deve ser uma conta de início de sessão. Entre como um utilizador com nome e use sudo; assim cada ação privilegiada é atribuível a uma pessoa.
Os valores intermédios existem por uma razão, e vale a pena conhecê-los em vez de os temer. O forced-commands-only permite o início de sessão de root apenas quando a chave apresentada está restrita a um único comando no authorized_keys — o padrão que os scripts de cópia de segurança e monitorização usam — e é uma escolha legítima e deliberada para a automação. O que não é legítimo é yes, que permite o início de sessão de root com palavra-passe e é um erro em qualquer auditoria. A regra prática: se um humano entra como root, a configuração está errada; se for um script, restrinja a chave a um comando e diga-o num comentário, porque a próxima pessoa a ler o ficheiro vai «corrigi-lo» se não o fizer.
A retirada de algoritmos é um alvo em movimento
Os algoritmos da sua configuração têm prazo de validade, e é mais curto do que pensa. O OpenSSH 10.0, publicado a 2025-04-09, removeu por completo o suporte a DSA (ssh-dss), retirou o Diffie-Hellman de campo finito da troca de chaves por omissão do servidor e fez do mlkem768x25519-sha256 — um híbrido pós-quântico — o acordo de chaves por omissão. Uma configuração copiada de um blogue de 2021 pode continuar a listar diffie-hellman-group1-sha1, 3des-cbc, arcfour ou hmac-md5, todos erros numa auditoria moderna, e alguns dos quais o daemon instalado já nem sequer suporta. A configuração não mudou; o mundo mudou.
É por isso que uma base de reforço tem de trazer uma data, e por isso voltar a verificar faz parte do trabalho, não é um pensamento posterior. O perfil Modern da Mozilla — troca de chaves curve25519, cifras chacha20-poly1305 e AES-GCM, MAC SHA-2 de cifrar-e-depois-autenticar — é a referência, mas é anterior às trocas de chaves pós-quânticas que o OpenSSH 10.0 tornou por omissão, por isso uma auditoria de 2026 aceita mlkem768x25519-sha256 e sntrup761x25519-sha512 juntamente com elas. O hábito que o mantém atualizado é barato: uma ou duas vezes por ano, execute ssh -Q kex, ssh -Q cipher e ssh -Q mac no servidor para ver o que a versão instalada realmente oferece, compare com as diretrizes atuais da Mozilla e volte a passar o auditor sobre o mesmo ficheiro. Uma pontuação limpa de 2021 é um documento histórico, não um documento atual.
Blocos Match e Include: as duas formas de uma auditoria limpa mentir
Um ficheiro de configuração não é uma lista plana de definições: é um programa com ramos condicionais, e duas funcionalidades podem fazer com que um ficheiro que se lê como reforçado se comporte como se não estivesse. A primeira é o bloco Match: as diretivas dentro de Match User, Match Group ou Match Address só se aplicam quando os critérios se verificam, e a página do manual é explícita: se uma palavra-chave aparecer em vários blocos Match satisfeitos, só se aplica a primeira instância. Um PasswordAuthentication no global seguido de um bloco Match que volta a ativar discretamente as palavras-passe para um grupo é uma configuração real, e é exatamente o tipo de coisa que uma leitura linha a linha deixa passar. Os achados de dentro de um bloco Match são condicionais, nunca globais, e qualquer auditoria honesta delimita-os assim.
A segunda é o Include. As distribuições modernas dividem o sshd_config por vários ficheiros — /etc/ssh/sshd_config.d/*.conf é o padrão habitual — e uma diretiva Include incorpora esses ficheiros, por ordem léxica, no ponto em que aparece. Como ganha o primeiro valor obtido, uma diretiva fixada num ficheiro incluído eclipsa a mesma diretiva mais adiante no ficheiro principal: a linha que lê não é a linha que manda. Um auditor que corre no navegador não consegue seguir os Includes — os ficheiros não estão na sua máquina — por isso marca-os como «não seguidos» e lista o caminho. Quando auditar, audite todo o diretório, não um só ficheiro, e lembre-se de que uma diretiva duplicada não é um erro de digitação a ignorar: a primeira ganha e a segunda é texto morto que vai confundir a próxima pessoa a editar o ficheiro.
A implementação segura: teste antes de fechar a porta
Cada mudança no sshd_config traz o mesmo risco: um erro de digitação pode impedir o daemon de reiniciar, e uma definição correta mas errada pode impedi-lo a si de entrar. A implementação que evita ambas é curta e inegociável. Primeiro, verifique a sintaxe com sshd -t antes de tocar no serviço em execução — analisa o ficheiro e reporta erros sem iniciar nada. Depois reinicie ou recarregue o daemon, e só então teste. Nunca edite a configuração e feche a sua única sessão no mesmo gesto.
O teste em si é a disciplina: mantenha a sua sessão atual aberta, abra uma segunda sessão e inicie sessão de novo com as novas regras em vigor. Se o segundo início funcionar, a mudança é segura e a primeira sessão pode fechar-se; se não, a sessão aberta é o seu caminho de volta, e pode reverter o ficheiro e recarregar. É também por isso que as mudanças devem ser feitas uma de cada vez num servidor a que não consegue chegar fisicamente — um ficheiro de chaves partido e um método de palavra-passe desativado na mesma edição não deixam saída nenhuma. O auditor pode produzir uma versão reforçada do seu ficheiro como ponto de partida, mas é um rascunho para rever, bloco Match a bloco Match, e testar com sshd -t — nunca um ficheiro para largar sem rever.