SSH Seguro – Parte 1

Torne o seu acesso SSH seguro de verdade, vamos usar chaves e fail2ban para deixar tudo muito mais robusto.

O que é o SSH :  Secure Shell, é um protocolo de rede que permite acesso remoto seguro a computadores e servidores, realizando tarefas como login e transferência de arquivos através de uma conexão criptografada e autenticada. Ele protege dados sensíveis em redes inseguras, garantindo a confidencialidade e a integridade das informações trocadas, e é amplamente utilizado para administração de sistemas, desenvolvimento de software e acesso a repositórios como o GitHub. 

O que é o fail2ban : é uma ferramenta gratuita de código aberto para prevenir ataques de força bruta em servidores Linux, monitorando arquivos de log em busca de tentativas de login falhas e bloqueando automaticamente os endereços IP mal-intencionados usando um firewall (como iptables) por um tempo determinado. Ele é flexível, pode ser configurado para proteger diferentes serviços (como SSH e Apache) e ajuda a aumentar a segurança geral de um servidor. 

Mas se o SSH já é seguro , porque melhorar ainda mais a segurança ?

Deixa eu explicar uma coisa, você pode investir em toda tecnologia do mundo, mas quase sempre vai ter um individuo de natureza despreocupada que vai usar por comodidade ou pura preguiça uma senha do tipo “sodeussalva” ou “P@$$w0rd” ou o próprio nome como senha, para este tipo de pessoa, o melhor é não permitir que ele digite uma senha para se autentica, dê para ele uma chave privada, que permita o acesso sem senha , pode parecer algo antagônico a segurança tal ideia, mas vamos a alguns fatos.

Autenticação por usuário + senha

Ataque mais comum: força bruta (brute force), onde bots tentam milhões de combinações de usuário/senha. Problema: mesmo senhas fortes podem cair em vazamentos ou ataques de dicionário.

Exposição real: pesquisas de segurança mostram que servidores SSH abertos na internet recebem milhares de tentativas de login por senha por dia (quase sempre automatizadas).

Autenticação por chave pública (public/private key)

A chave privada é um arquivo criptográfico; não há senha para tentar adivinhar diretamente. O servidor só valida se a chave enviada corresponde à pública cadastrada no authorized_keys. Para que um invasor acesse, precisaria roubar sua chave privada e

descobrir a passphrase dela (se você configurou uma).

Força bruta contra chave SSH moderna (ex.: Ed25519, RSA 4096) é computacionalmente inviável.

Explicado os fatos vamos para o mão na massa :

Estamos admitindo que você já tem o seu servidor configurado e rodando o serviço de sshd, e para efeitos de didatica vamos estabelecer o seguinte cenário

Servidor : SRV001

Sistema operacional : Debian 12

IP Privado : 192.168.10.10/24

observações:

O SSH já está configurado para não aceitar autenticação como root , sim isso é uma boa prática de segurança.

Existe um usuario userteste com a senha : 123@VouMudar

Estação : DESK01

Sistema Operacional : Linuxmint

IP Privado : (DHCP)

Usertest é um daqueles indivíduos antes citado, preguiçoso por natureza, que insiste em nunca mudar a senha fraca pois ele já sabe decorada, ele esta na estação dele e resolve que não quer mais nem digitar a senha de acesso e para isso pede ajuda ao administrador da rede.

No terminal da maquina do Usertest ele inicia os trabalhos :

DESK01:~$ ssh-keygen -t ed25519 -f ~/.ssh/id_usertest -a 100 -C "Chave do UserTest"

Vamos explicar algumas coisas , o ss-keygen, pelo próprio nome é autoexplicativo, a opção -t define o algoritmo da chave , veja tabela abaixo

A opção -b informa o número de bits da chave , deve ser usada somente quando aplicável, para o ed25519 não é necessário

A opção -f, determina o local onde devem ser salvas as chaves , por padrão devem ser salvas no diretorio .ssh do usuário , no exemplo será criado as chaves com o nome id_usertest no diretório .ssh do usuário logado (~).

Para determinar as iterações para derivar a chave da senha , use a opção -a número, onde número determina a quantidade de rodados do KDF (Key Derivation Function), quanto maior, mais lento para testar senhas em ataque de força bruta.Recomendado: pelo menos 100.

O -C adiciona uma etiqueta na chave pública.

Você digitou o comando e algumas coisas vão acontecer , uma dela é que o ssh-keygen vai solicitar uma Passphrase

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): 

Você pode até ficar tentado a deixa sem uma passphrase, mas confie neste autor, coloque uma , algo significativo como ‘cafecomleiteemuitobom’

Enter same passphrase again: 
Your identification has been saved in /home/usertest/.ssh/id_usertest
Your public key has been saved in /home/usertest/.ssh/id_usertest.pub
The key fingerprint is:
SHA256:ASTq3JuBu1FHLYr9VEFUJcz/i105Ez4qb7VWRXHnbvc Chave do UserTest
The key's randomart image is:
+--[ED25519 256]--+
|    ..oo++o..  .+|
|   . . o .o.   .+|
|  .   o +  .   ..|
| o = o o .  .  o.|
|  = * o S    .. B|
|   o B        .O=|
|  o o .      oooE|
|   o       ..ooo |
|  .         +..  |
+----[SHA256]-----+

Pronto você confirmou sua passphrase e ele gerou as duas chaves, a pública e a privada.

Ufa! Mas não acabou, temos de publicar no servidor nossa chave publica, para isso vamos usar outra aplicação o ssh-copy-id.

DESK01:~$ ssh-copy-id -i ~/.ssh/id_usertest.pub usertest@192.168.10.10

O que faz este comando, ele vai até o servidor onde deve ser publicado a chave pública, fazer uma conexão via ssh usando as credencias do usertest e cópia a chave pública em sua estrutura.

Pois bem, neste momento o que deveriamos fazer no DESK01, está quase concluso, mais ainda a algo para fazer . Se uma passphrase foi definida, sempre que for feita tentativa de conexão ele vai pedir a passphrase, para isso devo ativar o ssh-agent conforme comando abaixo

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_usertest

No caso do Linuxmint se estiver em um ambiente gráfico ele vai aparecer uma janela pedindo para salvar a passphase.

Acabou para o nosso amigo preguiçoso, mas atenção, o problema foi resolvido no DEKS01, ainda é possível acessar o ssh com usuário e senha em outra estação, e isso ainda é um problema, então para nosso destemido administrador de rede a luta apenas começou. No próximo artigo, SSH sem usuário e senha e outras configurações.

Por enquanto é só.