Restrinja as tentativas de senha no Linux para proteger o SSH e os serviços.

Se você gerencia um servidor Linux exposto à Internet, mais cedo ou mais tarde você verá isso nos logs. milhares de tentativas de login SSH a partir de endereços IP aleatóriosNão é que eles tenham antipatia por você: são bots automatizados que percorrem faixas de IP em busca de portas mal protegidas.

Em um servidor pequeno, essas tentativas podem se traduzir em Picos de uso da CPU, degradação de desempenho e até mesmo interrupções ocasionais do serviço.A boa notícia é que o Linux oferece um arsenal de ferramentas para limitar tentativas de senha, bloquear IPs agressivos e reforçar a segurança do SSH, tornando a ação de um invasor muito difícil.

Detecção de ataques de força bruta em SSH e seu impacto no servidor.

Antes de começarmos a configurar qualquer coisa, é útil entender como detectar se estamos enfrentando um problema. ataque de força bruta contra SSH ou outros serviçose quais os efeitos que isso tem na máquina.

Um sintoma muito típico é ver um um aumento repentino no uso da CPU sem qualquer alteração no tráfego legítimo ou na carga do banco de dadosPor exemplo, você pode ter um pico de uso da CPU por alguns minutos, enquanto o uso de memória e disco permanece praticamente estável, o que geralmente indica processos que exigem muito poder computacional (como muitas tentativas de autenticação) em vez de consultas complexas.

Para analisar o que aconteceu em um intervalo específico, é muito útil usar jornalctlA ferramenta systemd para leitura de logs de sistema, serviço, kernel e autenticação. Um exemplo clássico de consulta seria:

journalctl --since "2025-11-16 13:10" --until "2025-11-16 13:16"

Com esse tipo de consulta, você pode analisar em detalhes. Que mensagens o sistema registrou durante o período em que houve um pico de uso da CPU?Serviços que reiniciam, falhas de autenticação, erros de kernel, etc.

Em muitos casos, você encontrará linhas repetidas relacionadas ao SSH, como: "Senha incorreta para" indicando tentativas de login falhasIsso é praticamente sinônimo de bots realizando testes de credenciais por força bruta.

Quantificar tentativas falhas em /var/log/auth.log

Em sistemas Debian/Ubuntu, o arquivo de chave para rastrear tudo relacionado à autenticação é /var/log/auth.logÉ aqui que são registrados os logins bem-sucedidos, as tentativas falhas, os eventos PAM, os bloqueios de conta, etc.

Se você quiser saber quantas vezes o padrão foi registrado "Senha incorreta" no registro atual, você pode usar:

sudo grep 'Failed password' /var/log/auth.log | wc -l

O resultado pode ser surpreendente: não é incomum ver Milhares de tentativas fracassadas se acumularam em questão de horas.E lembre-se que isso é apenas o arquivo atual.

Como os registros são rotacionados, é importante também revisar os arquivos mais antigos. Você pode ver o intervalo de tempo que o registro atual abrange com um comando como:

head -n 1 /var/log/auth.log
tail -n 1 /var/log/auth.log

Assim você saberá o Data do primeiro e do último registro presente em auth.logO restante das tentativas anteriores estará em auth.log.1 e nos arquivos compactados auth.log.N.gz.

Para revisar registros antigos compactados e contabilizar tentativas de senha incorretas, você pode usar:

zgrep 'Failed password' /var/log/auth.log.*.gz | wc -l

Se você somar o que vê em auth.log, auth.log.1 e auth.log.*.gz Você terá uma boa ideia do ​​ Registro histórico de ataques de força bruta, levando em consideração que os mais antigos podem já ter desaparecido devido à rotação.

Como funciona a rotação do log de autenticação

A forma e a frequência com que os troncos giram dependem da configuração de alcançadoNo Ubuntu, a rotação do arquivo auth.log geralmente é definida em /etc/logrotate.d/rsyslog, onde você normalmente encontrará algo como:

weekly
rotate 4
compress

Isso significa que O registro é rotacionado semanalmente, quatro cópias antigas são mantidas e as antigas são compactadas em arquivos .gz.Uma tarefa cron diária é responsável por executar o logrotate e aplicar essas regras.

Portanto, ao calcular suas tentativas de força bruta, assuma que Você está vendo apenas os dados históricos de algumas semanas atrás.Tudo o que aconteceu em um passado mais remoto não estará mais no sistema.

Identificar usuários e endereços IP atacantes

Além da contagem total, é importante saber Quais usuários estão sendo alvo dos ataques e de quais endereços IP eles estão sendo originados?Com um pouco de awk no arquivo auth.log, você o terá à mão.

Para ver quais nomes de usuário estão sendo tentados nas tentativas falhas:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-5)}' \
  | sort | uniq -c

E para ver os endereços IP com a atividade mais suspeita:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | head

Isso permitirá que você detecte rapidamente se eles estão atacando. contas reais do seu sistema ou usuários genéricos tais como root, admin, test, user, etc., e quais IPs você deve bloquear com mais urgência.

Será mesmo tão grave a ponto de haver milhares de tentativas?

Deve-se presumir que, se o seu servidor for acessível pela Internet e tiver SSH escutando na porta 22 ou em qualquer outra.Este servidor receberá esse tipo de tráfego 24 horas por dia. É normal observar milhares de tentativas falhas se o servidor estiver em funcionamento há algum tempo.

A gravidade real depende das suas configurações:

configuração	Risco aproximado
Senhas fracas + SSH aberto para a Internet	Risco muito elevado de comprometimento.
Senhas fortes	Risco moderado, mas consumo de recursos
Fail2ban configurado corretamente	Ataques de baixo risco e altamente mitigados
Acesso somente com chaves SSH	Risco muito próximo de zero por força bruta

Em outras palavras: ataques automatizados são comuns, mas se sua configuração for permissiva, Basta uma única senha incorreta para você perder o acesso a todo o servidor.Por isso é tão importante limitar as tentativas, bloquear endereços IP e, sempre que possível, eliminar senhas.

Reforço básico da segurança do SSH: opções críticas no sshd_config

A primeira linha de defesa está dentro de cada um. Daemon SSH (sshd) e seu arquivo de configuração /etc/ssh/sshd_config (e os arquivos .d associados). Algumas diretivas bem configuradas reduzem bastante a superfície de ataque.

Lembre-se de que em distribuições modernas como o Ubuntu 22.04 e versões posteriores, O sshd primeiro lê /etc/ssh/sshd_config e depois os arquivos em /etc/ssh/sshd_config.d/*.conf Em ordem alfabética. Qualquer alteração feita posteriormente pode sobrescrever parâmetros definidos anteriormente, portanto, tenha muito cuidado com o que você modifica.

Desative o acesso sem senha e sessões desnecessárias.

Embora venha bem configurado na maioria das distribuições modernas, não custa confirmar se... Não são permitidos logins sem senha definida.A diretriz principal é:

PermitEmptyPasswords no

Geralmente, essa linha é comentada ou definida explicitamente como "não". Além disso, certifique-se de desativar os recursos que você não usará, como... Encaminhamento X11 (X11Forwarding) Se você não realiza sessões gráficas remotas:

X11Forwarding no

Em relação aos protocolos, se por algum motivo você estiver gerenciando um sistema muito antigo, verifique se apenas determinadas ações são permitidas. Protocolo SSH 2:

Protocol 2

Altere a porta padrão e limite a interface em que ela escuta.

Outro truque simples, embora não infalível, é Mova o SSH da porta 22 para uma porta não padrão.Isso não te protege de um ataque sério, mas filtra uma quantidade significativa de ruído automatizado que só verifica os 22.

Port 2222
ListenAddress 192.168.56.8

Além de alterar a porta, você pode especificar um endereço específico no qual o SSH ficará escutando, por exemplo, seu endereço IP interno se quiser restringi-lo a uma rede específica. No entanto, se sua distribuição usa o ssh.socket do systemd, talvez seja necessário... Desative o socket e retorne ao serviço ssh clássico. Para respeitar a configuração da porta:

sudo systemctl disable ssh.socket
sudo systemctl daemon-reload
sudo systemctl enable ssh.service
sudo systemctl start ssh.service

Sempre que alterar a porta, teste a conexão a partir de outro terminal antes de fechar a sessão principal, para não ficar sem acesso remoto.

Bloquear ou limitar o acesso root

O usuário root é uma presa fácil para atacantes, então faz sentido. Impedir a conexão via SSHmesmo com senhas. Você controla esse comportamento com a diretiva:

PermitRootLogin no

Em muitas instalações modernas, ele vem no modo "proibir senha", que impede logins com senha, mas permite o uso de certificados. Se você quiser garantir a segurança, deixe-o configurado como "não" e use uma conta comum com privilégios de administrador (sudo).

Defina quem pode acessar: PermitirUsuários e PermitirGrupos

Por padrão, qualquer usuário com shell válido e senha definida Você pode tentar conectar via SSH. Geralmente, essa não é a opção ideal em servidores de produção, onde talvez apenas duas ou três contas devam ter acesso.

Para limitar o número de usuários permitidos, você tem as seguintes diretrizes. Permitir usuários y PermitirGrupos. Por exemplo:

AllowUsers harry hermione
AllowGroups gryffindor

A lista é separada por espaços e a semântica é a de uma "lista branca": Somente as contas e os grupos listados poderão se autenticar.Lembre-se também de que AllowUsers tem precedência sobre AllowGroups, portanto, não os misture a menos que tenha clareza sobre a ordem de avaliação.

Uma boa prática é trabalhar principalmente com grupos típicos. usuários ssh ou administradores e adicione as contas autorizadas ali, em vez de manter uma lista de usuários um por um no arquivo.

Limitar tentativas de autenticação e tempo de inatividade

Outra camada de proteção está em Reduza o número de tentativas de conexão malsucedidas permitidas em uma única conexão. e por quanto tempo uma sessão pode permanecer inativa. Para a primeira pergunta, você pode usar:

MaxAuthTries 3

Com isso, o servidor fechará a conexão após três tentativas incorretas, o que Isso torna menos eficaz qualquer ataque que tente várias senhas na mesma sessão SSH..

Com relação ao tempo ocioso, o SSH permite encerrar conexões que permanecem abertas sem atividade além de um limite definido. IntervaloClienteAtivo (em segundos):

ClientAliveInterval 180

Após três minutos sem tráfego, o servidor enviará mensagens de keepalive e, se o cliente não responder, A sessão será encerrada automaticamente.É uma forma de reduzir os riscos associados a terminais esquecidos e destrancados.

Restringir o acesso por endereço IP: TCP Wrappers e Match

Em alguns cenários, você pode estar interessado em Apenas determinados endereços IP ou intervalos de endereços podem acessar via SSH.Você tem várias maneiras de fazer isso: pelo próprio firewall (iptables/nftables), passando pelos TCP Wrappers, até os blocos Match do sshd_config.

Com o TCP Wrappers, ainda usado em muitas distribuições, o acesso é controlado pelos arquivos /etc/hosts.allow e /etc/hosts.deny. O fluxo é o seguinte: Primeiro, hosts.allow é avaliado e, em seguida, hosts.deny.Um exemplo restritivo seria:

# /etc/hosts.deny
ALL: ALL

# /etc/hosts.allow
sshd: 192.168.1.89 192.168.1.55
sshd: ALL: DENY

Com essa configuração, Apenas dois hosts específicos poderão se conectar via SSH.e o restante será negado. É muito eficaz em ambientes fechados, embora menos flexível do que um bom firewall moderno.

Outra opção, mais típica do SSH, é usar blocos. Match Dentro do arquivo sshd_config, você pode aplicar regras com base no endereço ou no usuário. Imagine que você queira que o usuário "git" possa fazer login de qualquer lugar, mas o usuário administrador "greg" só possa fazer login na rede local 192.168.1.0/24. Você poderia combinar as regras AllowUsers com as regras Match Address, embora deva ter muito cuidado para... Não se isole de si mesmo..

Fail2ban: Bloqueios automáticos versus força bruta

Mesmo reforçando a segurança do SSH, os bots ainda tentarão acessar as credenciais, causando uso excessivo da CPU e ruído nos logs. Para mitigar esse problema, essa solução entra em ação. Fail2ban, um sistema de prevenção de intrusões baseado em registros. que bloqueia automaticamente os endereços IP com muitos erros.

O Fail2ban é escrito em Python e depende de "prisões" ou prisões, cada uma associada a um serviço e um ou mais arquivos de log.Ao detectar um padrão de erro repetido (falhas de senha, acesso proibido, etc.), ele aciona ações, geralmente regras de firewall para bloquear a origem.

Instale o Fail2ban nas distribuições Linux mais comuns.

A instalação básica é bastante simples, utilizando o gerenciador de pacotes da sua distribuição. No Ubuntu ou Debian, isso seria suficiente:

sudo apt update
sudo apt install fail2ban

Em sistemas baseados em RHEL (RHEL, CentOS, AlmaLinux, Rocky, etc.), o comando típico seria com dnf ou yum, dependendo da versão.:

sudo dnf install fail2ban

O pacote geralmente inclui um serviço systemd que inicia automaticamente, embora seja recomendável verificar isso. O Fail2ban inicia na inicialização do sistema e permanece ativo.:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo systemctl status fail2ban

Estrutura de configuração: jail.conf, jail.local e jail.d

A configuração reside em /etc/fail2ban/O arquivo principal é o jail.conf, mas não é recomendável editá-lo diretamente, pois ele será sobrescrito durante as atualizações. Em vez disso, você deve:

• Crie ou edite o arquivo /etc/fail2ban/jail.local Sobrescrever os valores padrão.
• Ou adicione arquivos específicos em /etc/fail2ban/jail.d/*.conf.

O Fail2ban carrega a configuração nesta ordem:

/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.local

Tudo o que você definir em jail.local terá precedência sobre tudo o que veio antes, portanto Você pode personalizar sem alterar os arquivos do pacote..

Parâmetros globais importantes: bantime, maxretry, ignoreip

Dentro do arquivo jail.conf (ou jail.local), você encontrará uma seção [DEFAULT] com parâmetros globais que afetam todas as jails, a menos que sejam sobrescritos. Os mais importantes são:

• hora de banimentoTempo durante o qual um endereço IP será bloqueado (em segundos) após exceder o número de falhas permitidas.
• maxretria: número máximo de tentativas falhas antes da aplicação da proibição.
• Encontre tempo: período de tempo em que essas tentativas são contabilizadas (por exemplo, 10m durante dez minutos).
• ignorarLista de IPs ou intervalos que o Fail2ban nunca deve bloquear (por exemplo, seu próprio IP público ou sua rede de gerenciamento).

Por exemplo, você poderia ter algo como isto em [DEFAULT]:

[DEFAULT]
bantime  = 600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24

Com essa configuração, Qualquer endereço IP que falhar cinco vezes em dez minutos será bloqueado por dez minutos., a menos que faça parte dos intervalos ignorados.

Configure o jail sshd para impedir ataques SSH.

O ambiente de segurança mais comum é o ambiente SSH. Em muitas distribuições, ele já vem pré-configurado no arquivo jail.conf; basta ativá-lo ou ajustar seus valores no arquivo jail.local. Um exemplo simples:

[sshd]
enabled  = true
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 600
findtime = 10m

Neste caso, Três tentativas de login falhas registradas no arquivo auth.log em um período de dez minutos resultarão no bloqueio do endereço IP do atacante por dez minutos.O Fail2ban injeta regras no firewall (iptables, nftables ou UFW, dependendo do sistema) para que as conexões desse IP nem cheguem ao sshd.

Para aplicar as alterações de configuração, lembre-se de reiniciar o serviço:

sudo systemctl restart fail2ban

Veja o status das prisões e dos IPs bloqueados.

O Fail2ban inclui um utilitário de controle muito prático, cliente fail2banCom esta ferramenta, você pode ver quais prisões estão ativas e quais IPs foram bloqueados. Por exemplo:

sudo fail2ban-client status

Isso mostraria algo semelhante a:

Status
|- Number of jail: 1
`- Jail list: sshd

Para informações detalhadas sobre a prisão do SSHD:

sudo fail2ban-client status sshd

A saída inclui, entre outros campos, o número de IPs atualmente banidos e o Número total histórico de endereços que foram bloqueados pelo menos uma vez, além da lista de IPs em andamento.

Com esses dados, você pode ter uma ideia de Qual o volume de tráfego malicioso que seu servidor está recebendo e qual a eficácia da configuração atual?.

Bloqueios permanentes e tempo de banimento incremental

Se você quiser ser especialmente rigoroso com infratores reincidentes, o Fail2ban oferece duas estratégias interessantes: proibição permanente e proibição gradual.

Para banir permanentemente qualquer endereço IP que exceda o limite de falhas, basta digitar:

bantime = -1

Com esse ajuste, Os endereços IP sancionados nunca são desbloqueados automaticamente.Você só poderá removê-los manualmente se for necessário.

Mais flexível é o mecanismo incremental, no qual cada reincidência aumenta o tempo de suspensão de acordo com um fator:

bantime           = 10m
bantime.increment = true
bantime.rndtime   = 0
bantime.factor    = 4
bantime.maxtime   = -1

Com esses valores, a progressão seria algo como isto:

• 1º bloco: Minutos 10
• 2º bloco: Minutos 40
• 3º bloco: Minutos 160 (aproximadamente 2 horas e 40 minutos)
• 4º quarteirão: por volta de 10,6 horas
• 5º bloco: alguns 42 horas

Como bantime.maxtime é -1, o A duração pode continuar a crescer indefinidamente., deixando os jogadores realmente importantes fora do jogo para sempre.

Utilizando o Fail2ban além do SSH: Apache, WordPress, MySQL, lojas online…

Depois de dominar o Fail2ban, o mais lógico é estendê-lo para... Proteja outros serviços sensíveis além do SSH.Painéis de administração web, CMS, bancos de dados, etc.

Por exemplo, para uma loja online (Magento, PrestaShop, WooCommerce…) faz muito sentido criar um ambiente controlado (jail) que monitore o Os logs de acesso do Apache ou Nginx procuram por muitos códigos 401/403 em /admin ou /login.Uma configuração mínima baseada no Apache poderia ser:

[apache-auth]
enabled  = true
filter   = apache-auth
logpath  = /var/log/apache2/access.log
maxretry = 5
bantime  = 3600

Em ambientes WordPress, uma combinação comum é monitorar /wp-login.php e /xmlrpc.phpEsses são os pontos de entrada clássicos para ataques de força bruta e bots. O filtro pode ser colocado em /etc/fail2ban/filter.d/wordpress.conf:

[Definition]
failregex = .*"POST /wp-login.php HTTP.*" 403
ignoreregex =

E a prisão correspondente em jail.local:

[wordpress]
enabled  = true
filter   = wordpress
logpath  = /var/log/apache2/access.log
maxretry = 3
bantime  = 3600

A mesma ideia se aplica a bancos de dados expostos (algo que geralmente é melhor evitar): se você quiser proteger o MySQL de tentativas contínuas de acesso sem sucesso, você pode criar um filtro para o mensagens de “Acesso negado para o usuário” no registro de erros:

[Definition]
failregex = ^<HOST>.*Access denied for user.*$
ignoreregex =

E depois prisão:

[mysqld-auth]
enabled  = true
filter   = mysql
logpath  = /var/log/mysql/error.log
maxretry = 5
bantime  = 1800

Sobre hospedagem de servidores com painéis de controle cPanel ou PleskO Fail2ban também se integra bem: ele pode monitorar serviços de e-mail, Apache, FTP e até mesmo o próprio painel de controle, bloqueando IPs que ultrapassam os limites com tentativas de login.

Autenticação com chaves SSH: o fim dos ataques de senha.

Tudo isso ajuda, mas o verdadeiro salto de qualidade acontece quando você decide Pare de usar senhas para SSH e passe a usar chaves públicas/privadas.Nesse ponto, os ataques de força bruta a senhas deixam de fazer sentido.

A ideia é simples: cada usuário legítimo possui um par de chaves, um chave privada que permanece no seu dispositivo e um chave pública que é copiada para o servidor no arquivo ~/.ssh/authorized_keys do usuário correspondente.

Quando o cliente se conecta, ele não envia a chave privada; ele envia a chave pública e, em seguida, assina um desafio de servidor com a assinatura privada. O servidor compara essa assinatura com a pública e só permite o acesso se elas coincidirem.

Por que as chaves SSH impedem ataques de força bruta contra senhas?

Em um esquema de senha clássico, o atacante simplesmente precisa testar sequências de texto até encontrar uma que corresponda à senha armazenada (ou ao seu hash). Embora uma boa senha tenha muitas combinações possíveis, Estamos falando de ordens de grandeza, como 10¹⁰ possibilidades para senhas comuns..

Uma chave SSH típica de 256 bits (como as do Ed25519) se move em espaços de busca na ordem de 10⁶¹⁷ combinaçõesNa prática, é matematicamente impossível para um atacante adivinhar uma chave privada por força bruta com os computadores modernos.

Mas, além disso, o servidor nem sequer tenta calcular nada se o A chave pública apresentada não está em authorized_keys.Nesse caso, a conexão é descartada quase imediatamente, sem invocar PAM ou processos de autenticação tradicionais, de modo que o consumo de CPU durante um ataque massivo é mínimo.

Gere e verifique as chaves SSH no cliente.

Antes de acessar o servidor, verifique se sua máquina já possui um par de chaves SSH gerado. Basta listar o conteúdo do arquivo ~/.ssh:

ls -l ~/.ssh

Se você vir arquivos como id_ed25519 e id_ed25519.pub Se você usar id_rsa e id_rsa.pub, já terá um par válido. O Ed25519 é mais moderno e leve, sendo geralmente a melhor opção atualmente.

Se você não tiver chaves, gere novas com:

ssh-keygen -t ed25519 -C "tu_usuario@tu_equipo"

O comando criará dois arquivos:

• id_ed25519: a chave privada, que você nunca deve compartilhar.
• id_ed25519.pub: a chave pública, que você pode copiar para os servidores.

Você pode visualizar o conteúdo da chave pública com:

cat ~/.ssh/id_ed25519.pub

Copie a chave pública para o servidor e teste o acesso.

No servidor, certifique-se de que o diretório ~/.ssh exista para o usuário com o qual você fará login (por exemplo, git ou seu usuário administrador) e que ele contenha as seguintes permissões: autorizações 700:

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

Em seguida, adicione o conteúdo do arquivo id_ed25519.pub do seu cliente ao ~ / .ssh / authorized_keys (criando o arquivo se ele não existir) e atribuindo permissões 600:

echo "TU_PUBLIC_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Lembre-se de substituir YOUR_PUBLIC_KEY pela linha completa que você viu ao usar o comando `cat` em sua máquina. A partir daí, você pode testar a conexão especificando explicitamente a chave, se desejar.

ssh -i ~/.ssh/id_ed25519 usuario@IP_DEL_SERVIDOR

Se tudo estiver bem, O servidor não solicitará uma senha e você acessará diretamente o shell.Nesse ponto, você estará pronto para considerar desativar a autenticação por senha.

Desative completamente a autenticação por senha no servidor.

Depois de verificar que consegue aceder à sua conta com a sua palavra-passe a partir de pelo menos um dispositivo (idealmente dois, caso perca um), é uma boa ideia Desativar login por senha para SSHIsso elimina qualquer tentativa de uso da força bruta clássica.

Antes de mexer na configuração, é uma boa ideia verificar quais arquivos definem a autenticação por senha, pois em muitas instalações modernas Existem arquivos .d que sobrescrevem o valor do arquivo sshd_config principal.:

sudo grep -R "PasswordAuthentication" /etc/ssh/

É comum encontrar algo como:

/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes
/etc/ssh/sshd_config:PasswordAuthentication no

Nesse caso, a configuração efetiva será "sim", pois o arquivo 50-cloud-init.conf é carregado posteriormente e sobrescreve o valor. Você pode verificar o resultado final aplicado pelo sshd com o seguinte comando:

sudo sshd -T | grep passwordauthentication

Para desativar as senhas reais, edite o arquivo responsável (por exemplo, /etc/ssh/sshd_config.d/50-cloud-init.conf) e deixe o seguinte:

PasswordAuthentication no

Em seguida, reinicie o serviço SSH:

sudo systemctl restart ssh

E confirme novamente com:

sudo sshd -T | grep passwordauthentication

Se retornar "não", As tentativas de login com senha serão rejeitadas imediatamente.Programas como o PuTTY exibirão um erro porque não conseguem fornecer credenciais do tipo senha, mas seus clientes com chaves continuarão funcionando sem problemas.

Combinar chaves SSH com Fail2ban e outras medidas.

Ao remover a autenticação por senha da equação, o valor do Fail2ban para SSH torna-se mais útil do que crítico, visto que Os bots nem sequer têm um campo para inserir a senha.Ainda assim, é aconselhável manter o jail do sshd ativo, pois ele serve como uma camada adicional contra tentativas incomuns de outros tipos ou uso indevido de chaves.

Se essa combinação de Somente chaves SSH + Fail2ban + bloqueio de root + listas AllowUsers/AllowGroups finamente configuradas Adicione um firewall restritivo (iptables/nftables, UFW, firewalld) e, se apropriado, listas de controle de acesso com TCP Wrappers, e você terá reduzido a probabilidade de intrusão por força bruta a um nível insignificante.

Em ambientes ainda mais sensíveis, você pode ir um passo além e introduzir Autenticação de dois fatores (2FA) para SSHUtilizando módulos como o Google Authenticator ou similares via PAM, ou até mesmo restringindo quem pode acessar a porta SSH usando VPNs dedicadas.

Com todos esses elementos bem integrados — detecção de logs, configuração cuidadosa do sshd, uso extensivo do Fail2ban, chaves SSH em vez de senhas e, quando necessário, controles baseados em IP — um servidor Linux pode lidar com a situação. ataques contínuos de força bruta contra SSH e outros serviços expostosmantendo, ao mesmo tempo, um acesso conveniente e seguro para os administradores.