Si administres un servidor Linux exposat a Internet, tard o d'hora veuràs als logs milers d'intents d'accés per SSH des de les adreces IP aleatòries. No és que t'hagin agafat mania: són bots automatitzats que recorren rangs d'IP buscant portes mal protegides.
En un servidor petit, aquests intents es poden traduir a pics d'ús de CPU, degradació del rendiment i fins i tot caigudes puntuals de serveis. La bona notícia és que Linux ofereix un arsenal d'eines per limitar els intents de contrasenya, bloquejar IPs agressives i reforçar SSH fins a deixar-ho molt difícil per a un atacant.
Detectar atacs de força bruta SSH i el seu impacte al servidor
Abans de posar-nos a configurar res, convé entendre com detectar que estem patint un atac de força bruta contra SSH o altres serveis, i quins efectes té sobre la màquina.
Un símptoma molt típic és veure un augment brusc de l'ús de CPU sense que canviï el trànsit legítim ni la càrrega de la base de dades. Per exemple, pots tenir un pic de CPU durant uns minuts mentre la memòria i el disc segueixen pràcticament plans, cosa que sol apuntar a processos intensius en còmput (com molts intents d'autenticació) i no tant a consultes pesades.
Per analitzar què estava passant en un interval concret, és molt útil estirar diarictl, l'eina de systemd per llegir logs de sistema, serveis, nucli i autenticació. Un exemple clàssic de consulta seria:
journalctl --since "2025-11-16 13:10" --until "2025-11-16 13:16"Amb aquest tipus de consulta podràs revisar amb detall quins missatges va registrar el sistema durant la finestra en què es va disparar la CPU: serveis que es reinicien, errors d'autenticació, errors de kernel, etc.
En molts casos et trobaràs amb línies repetides relacionades amb SSH, del tipus Failed password for que evidencien intents fallits de login. Això és pràcticament sinònim de bots provant credencials a allò brut.
Quantificar els intents fallits a /var/log/auth.log
En sistemes Debian/Ubuntu, el fitxer clau per seguir la pista a tot el que faci olor d'autenticació és /var/log/auth.log. Aquí es registren logins reeixits, intents fallits, esdeveniments de PAM, bloquejos de comptes, etc.
Si vols saber quantes vegades s'ha registrat el patró «Failed password» al log actual, Pots fer servir:
sudo grep 'Failed password' /var/log/auth.log | wc -lEl resultat pot ser sorprenent: no és estrany veure milers d'intents fallits acumulats en qüestió d'hores. I recorda que aquest és només el fitxer actual.
Com que els logs es roten, és important revisar també els fitxers anteriors. Podeu veure quin interval temporal cobreix el log actual amb alguna cosa com:
head -n 1 /var/log/auth.log
tail -n 1 /var/log/auth.logAixí sabràs la data del primer i últim registre presents a auth.log. La resta d'intents anteriors estaran a auth.log.1 i als fitxers comprimits auth.log.N.gz.
Per revisar els logs antics comprimits i comptar intents de contrasenya fallida, pots estirar:
zgrep 'Failed password' /var/log/auth.log.*.gz | wc -lSi sumes el que vegis a auth.log, auth.log.1 i auth.log.*.gz et faràs una bona idea del històric d'atacs de força bruta registrats, tenint en compte que els més vells ja poden haver desaparegut per la rotació.
Com funciona la rotació de logs d'autenticació
La forma i freqüència amb què roten els logs depèn de la configuració de logrotat. A Ubuntu, la rotació d'auth.log sol definir-se a /etc/logrotate.d/rsyslog, on és habitual trobar-se alguna cosa:
weekly
rotate 4
compressAixò vol dir que es trenca el log cada setmana, es guarden quatre còpies antigues i les velles es comprimeixen a .gz. Un cron diari s'encarrega d'executar logrotate i aplicar aquestes regles.
Per tant, quan facis els comptes d'intents de força bruta, assumeix que només veieu l'històric de diverses setmanes. El que hagi passat més enrere en el temps ja no estarà al sistema.
Identificar usuaris i IP atacants
Més enllà del recompte total, convé saber quins usuaris s'estan intentant explotar i des de quines adreces IP arriben els atacs. Amb una mica d'awk sobre auth.log ho tens a mà.
Per veure quins noms d'usuari s'estan provant en els intents fallits:
sudo grep 'Failed password' /var/log/auth.log \
| awk '{print $(NF-5)}' \
| sort | uniq -cI per veure les IPs amb més activitat sospitosa:
sudo grep 'Failed password' /var/log/auth.log \
| awk '{print $(NF-3)}' \
| sort | uniq -c | headAmb això podràs detectar ràpidament si estan atacant comptes reals del teu sistema o usuaris genèrics com a root, admin, test, usuari, etc., i quins IPs són les que hauries de bloquejar amb més urgència.
És tan greu que hi hagi milers d'intents?
Cal assumir que, si el vostre servidor és accessible des d'Internet i té SSH escoltant al port 22 oa qualsevol altre, rebrà aquest tipus de trànsit les 24 hores del dia. És normal que vegis milers d'intents fallits per poc que el servidor porti temps encès.
La gravetat real depèn de la teva configuració:
| Configuració | Risc aproximat |
|---|---|
| Contrasenyes febles + SSH obert a Internet | Risc molt alt de compromís |
| Contrasenyes robustes | Risc moderat, però consum de recursos |
| Fail2ban ben configurat | Risc baix i atacs molt mitigats |
| Només accés amb claus SSH | Risc molt proper a zero per força bruta |
En altres paraules: els atacs automatitzats són el pa de cada dia, però si la teva configuració és laxa, n'hi ha prou que falli una única contrasenya perquè perdis el servidor complet. Per això és tan important limitar intents, bloquejar IPs i, en la mesura del possible, treure del medi les contrasenyes.
Reforç bàsic de SSH: opcions crítiques a sshd_config
La primera línia de defensa és al propi daemon SSH (sshd) i el seu fitxer de configuració /etc/ssh/sshd_config (i els fitxers .d associats). Unes quantes directives ben ajustades redueixen molt la superfície d'atac.
Tingues en compte que en distribucions modernes com Ubuntu 22.04 i posteriors, sshd llegeix primer /etc/ssh/sshd_config i després els fitxers a /etc/ssh/sshd_config.d/*.conf en ordre alfabètic. El que aparegui després pot sobreescriure paràmetres definits abans, així que cal vigilar molt bé què toques.
Desactivar accessos sense contrasenya i sessions innecessàries
Encara que a la majoria de distribucions modernes ja ve ben configurat, no està de més confirmar que no es permeten inicis de sessió sense contrasenya definida. La directiva clau és:
PermitEmptyPasswords noEl més normal és que estigui comentada o posada explícitament a «no». Assegureu-vos també de tenir desactivades característiques que no utilitzeu, com el reenviat de X11 (X11Forwarding) si no fas sessions gràfiques remotes:
X11Forwarding noQuant a protocols, si pel que sigui administres un sistema molt vell, revisa que només es permeti SSH protocol 2:
Protocol 2Canviar el port per defecte i limitar en quina interfície escolta
Un altre truc senzill, encara que no definitiu, és moure SSH del port 22 a un no estàndard. Això no et protegeix d'un atacant seriós, però filtra una quantitat apreciable de soroll automatitzat que només escaneja el 22.
Port 2222
ListenAddress 192.168.56.8A més de canviar el port, pots especificar una adreça concreta on escoltarà SSH, per exemple la IP interna si el vols confinar a una xarxa concreta. Això sí, si la vostra distribució utilitza el socket ssh.socket de systemd, potser haureu de desactivar el socket i tornar al servei clàssic ssh.service perquè respecti la configuració de port:
sudo systemctl disable ssh.socket
sudo systemctl daemon-reload
sudo systemctl enable ssh.service
sudo systemctl start ssh.serviceSempre que canviïs el port, prova la connexió des d'una altra terminal abans de tancar la sessió principal, per no quedar-te llençat sense accés remot.
Bloquejar o limitar l'accés de root
L'usuari root és un caramel per als atacants, així que té sentit impedir que es connecti per SSH, fins i tot amb claus. Controles aquest comportament amb la directiva:
PermitRootLogin noEn moltes instal·lacions modernes ve en mode «prohibit-password», cosa que impedeix login amb contrasenya però deixa la porta oberta a certificats. Si vols anar al que és segur, deixa-ho a «no» i utilitza un compte normal amb sudo per a administració.
Definir qui hi pot accedir: AllowUsers i AllowGroups
Per defecte, qualsevol usuari amb shell vàlida i contrasenya definida podeu intentar connectar-vos per SSH. Això no sol ser ideal en servidors de producció, on potser només dos o tres comptes haurien de tenir accés.
Per fitar els usuaris permesos tens les directives AllowUsers y AllowGroups. Per exemple:
AllowUsers harry hermione
AllowGroups gryffindorLa llista se separa per espais i la semàntica és de «llista blanca»: només els comptes i grups llistats podran autenticar-se. Tingues en compte a més que AllowUsers té prioritat sobre AllowGroups, així que no abusis de barrejar ambdues tret que tinguis clar l'ordre d'avaluació.
Una bona pràctica és treballar principalment amb grups tipus sshusers o admins i afegir-hi als comptes autoritzats, en lloc d'anar mantenint una llista d'usuaris un a un al fitxer.
Limitar intents d´autenticació i temps d´inactivitat
Una altra capa de protecció és a reduir quants intents fallits es permeten en una sola connexió i quant de temps pot quedar una sessió inactiva. Per al primer pots fer servir:
MaxAuthTries 3Amb això, el servidor tancarà la connexió després de tres intents incorrectes, cosa que fa menys efectiu qualsevol atac que provi moltes contrasenyes contra la mateixa sessió SSH.
Pel que fa al temps d'inactivitat, SSH permet tallar connexions que es queden obertes sense activitat més enllà d'un llindar definit mitjançant ClientAliveInterval (en segons):
ClientAliveInterval 180Passats tres minuts sense trànsit, el servidor enviarà missatges keepalive i, si el client no respon, la sessió es tancarà automàticament. És una manera de reduir riscos per terminals oblidats oberts.
Restringir accés per adreça IP: TCP Wrappers i Match
En alguns escenaris et pot interessar que només certes IP o rangs puguin accedir per SSH. Tens diverses maneres de fer-ho: des del propi firewall (iptables/nftables), passant per TCP Wrappers, fins als blocs Match del sshd_config.
Amb TCP Wrappers, encara usats en moltes distribucions, es controlen accessos amb /etc/hosts.allow i /etc/hosts.deny. El flux és: primer s'avalua hosts.allow i després hosts.deny. Un exemple restrictiu seria:
# /etc/hosts.deny
ALL: ALL# /etc/hosts.allow
sshd: 192.168.1.89 192.168.1.55
sshd: ALL: DENYAmb aquesta configuració, només dos hosts concrets podran connectar-se per SSH, i la resta quedaran denegats. És molt efectiu en entorns tancats, encara que menys flexible que un bon firewall modern.
Una altra opció, més pròpia de SSH, és fer servir blocs Partit dins de sshd_config per aplicar regles segons adreça o usuari. Imagina que vols que un usuari git pugui entrar des de qualsevol lloc però que el teu usuari administrador greg només ho pugui fer des de la LAN 192.168.1.0/24. Podries combinar AllowUsers amb regles Match Address, encara que has de ser molt curós per no tancar-te l'accés a tu mateix.
Fail2ban: bloquejos automàtics davant de força bruta
Encara que enforteixis SSH, els bots seguiran provant credencials i provocant consum de CPU i soroll als logs. Per mitigar això és on entra en joc Fail2ban, un sistema de prevenció d'intrusions basat en logs que bloqueja automàticament les IP amb massa errors.
Fail2ban està escrit a Python i es recolza en «presons» o jails, cadascuna associada a un servei ia un o diversos fitxers de log. Quan detecta un patró d'error repetit (fallades de contrasenya, dreceres prohibides, etc.), llança accions, normalment regles de tallafocs per bloquejar a l'origen.
Instal·lar Fail2ban en distribucions Linux comunes
La instal·lació bàsica és força directa usant el gestor de paquets de la teva distribució. A Ubuntu o Debian n'hi hauria prou amb:
sudo apt update
sudo apt install fail2banEn sistemes basats en RHEL (RHEL, CentOS, AlmaLinux, Rocky, etc.), l'ordre típica seria amb dnf o yum, segons versió:
sudo dnf install fail2banEl paquet sol incloure un servei systemd que s'inicia automàticament, encara que convé comprovar que Fail2ban arrenca al boot i està actiu:
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo systemctl status fail2banEstructura de configuració: jail.conf, jail.local i jail.d
La configuració viu a /etc/fail2ban/. El fitxer principal és jail.conf, però no es recomana editar-lo directament perquè se sobreescriu en actualitzacions. Al seu lloc, hauries de:
- Crear o editar /etc/fail2ban/jail.local per sobreescriure valors per defecte.
- O bé afegir fitxers específics a /etc/fail2ban/jail.d/*.conf.
Fail2ban carrega la configuració en aquest ordre:
/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.localTot el que defineixis a jail.local preval sobre l'anterior, de manera que pots personalitzar sense tocar els fitxers del paquet.
Paràmetres globals importants: bantime, maxretry, ignoreip
Dins de jail.conf (o jail.local) veuràs una secció [DEFAULT] amb paràmetres globals que afecten totes les jails llevat que se sobreescriguin. Els més importants són:
- bantime: temps durant el qual una IP quedarà bloquejada (en segons) després de superar el nombre de fallades permeses.
- maxretria: nombre màxim d'intents fallits abans d'aplicar el ban.
- trobar temps: finestra de temps en què es compten aquests intents (ex. 10m per a deu minuts).
- ignorar: llista d'IPs o rangs que Fail2ban mai no ha de bloquejar (per exemple, la vostra pròpia IP pública o la vostra xarxa d'administració).
Per exemple, podries tenir alguna cosa tal que així a [DEFAULT]:
[DEFAULT]
bantime = 600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24Amb aquesta configuració, qualsevol IP que falli cinc vegades en deu minuts quedarà bloquejada deu minuts, llevat que formi part dels rangs ignorats.
Configurar la jail sshd per frenar atacs a SSH
La jail més típica és la de SSH. En moltes distribucions ja ve preparada a jail.conf, només cal activar-la o afinar els seus valors a jail.local. Un exemple senzill:
[sshd]
enabled = true
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 600
findtime = 10mEn aquest cas, tres intents fallits registrats a auth.log d'aquí a deu minuts provocaran un bloqueig de deu minuts de la IP atacant. Fail2ban injecta les regles al tallafocs (iptables, nftables o UFW, segons sistema) perquè les connexions d'aquesta IP ni tan sols arribin a sshd.
Per aplicar qualsevol canvi de configuració recordeu reiniciar el servei:
sudo systemctl restart fail2banVeure l'estat de les presons i IPs bloquejades
Fail2ban inclou una utilitat de control molt pràctica, fail2ban-client, amb la qual podeu veure quines presons estan actives i quins IPs s'han bloquejat. Per exemple:
sudo fail2ban-client statusMostraria una cosa semblant a:
Status
|- Number of jail: 1
`- Jail list: sshdPer veure informació detallada de la jail sshd:
sudo fail2ban-client status sshdLa sortida inclou, entre altres camps, el nombre d'IPs actualment banejades i el total històric d'adreces que han estat bloquejades almenys una vegada, més la llista d'IPs en curs.
Amb aquestes dades et pots fer una idea de quant trànsit maliciós està rebent el teu servidor i com efectiva és la configuració actual.
Bloquejos permanents i bantime incremental
Si vols ser especialment dur amb els reincidents, Fail2ban ofereix dues estratègies interessants: ban permanent i ban incremental.
Perquè qualsevol IP que superi el llindar de fallades quedi expulsada de forma indefinida, només cal posar:
bantime = -1Amb aquest ajustament, les IP sancionades no es desbloquegen mai de manera automàtica; només les podràs retirar tu manualment si ho necessites.
Més flexible és el mecanisme incremental, en què cada reincidència incrementa el temps de ban segons un factor:
bantime = 10m
bantime.increment = true
bantime.rndtime = 0
bantime.factor = 4
bantime.maxtime = -1Amb aquests valors, la progressió seria una cosa així:
- 1er bloqueig: 10 minuts
- 2n bloqueig: 40 minuts
- 3er bloqueig: 160 minuts (~2 hores i 40)
- 4t bloqueig: al voltant de 10,6 hores
- 5è bloqueig: unes 42 hores
Com que bantime.maxtime és a -1, la durada pot seguir creixent sense límit, deixant fora de joc per sempre els atacants realment pesats.
Utilitza Fail2ban més enllà de SSH: Apache, WordPress, MySQL, botigues online…
Quan li agafes el truc a Fail2ban, el més lògic és estirar-lo per protegir altres serveis sensibles a més de SSH: panells d'administració web, CMS, bases de dades, etc.
Per exemple, per a una botiga online (Magento, PrestaShop, WooCommerce…) té molt sentit crear una jail que vigili els registres d'accés d'Apache o Nginx a la recerca de molts codis 401/403 a /admin o /login. Una configuració mínima basada en Apache podria ser:
[apache-auth]
enabled = true
filter = apache-auth
logpath = /var/log/apache2/access.log
maxretry = 5
bantime = 3600En entorns WordPress, una combinació freqüent és monitoritzar /wp-login.php i /xmlrpc.php, que són les portes clàssiques per a atacs de força bruta i de bots. El filtre podria anar a /etc/fail2ban/filter.d/wordpress.conf:
[Definition]
failregex = .*"POST /wp-login.php HTTP.*" 403
ignoreregex =I la jail corresponent a jail.local:
[wordpress]
enabled = true
filter = wordpress
logpath = /var/log/apache2/access.log
maxretry = 3
bantime = 3600Igual idea per a bases de dades exposades (cosa que en general convé evitar): si vols protegir MySQL d'accessos fallits continus, pots crear un filtre per als missatges «Access denied for user» al log d'errors:
[Definition]
failregex = ^<HOST>.*Access denied for user.*$
ignoreregex =I després la jail:
[mysqld-auth]
enabled = true
filter = mysql
logpath = /var/log/mysql/error.log
maxretry = 5
bantime = 1800A servidors de hosting amb panells tipus cPanel o Plesk, Fail2ban també s'integra bé: pot monitoritzar serveis de correu, Apache, FTP, i fins i tot el mateix tauler de control, bloquejant IPs que es passin de frenada amb els intents de login.
Autenticació amb claus SSH: la fi dels atacs de contrasenya
Tot això ajuda, però el salt de qualitat real arriba quan decideixes deixar d'usar contrasenyes per a SSH i passar-te a claus públiques/privades. En aquell moment, els atacs de força bruta per contrasenya deixen de tenir sentit.
La idea és senzilla: cada usuari legítim té un parell de claus, una clau privada que es queda al dispositiu i una clau pública que es copia al servidor al fitxer ~/.ssh/authorized_keys de l'usuari corresponent.
Quan el client es connecta, no envia la clau privada; envia la clau pública i després signa un desafiament del servidor amb la privada. El servidor comprova aquesta signatura amb la pública, i només si coincideix permet accedir-hi.
Per què les claus SSH anul·len la força bruta de contrasenyes
En un esquema de contrasenya clàssica, l'atacant simplement ha d'anar provant cadenes de text fins que coincideixi amb l'emmagatzemada (o el seu hash). Tot i que una bona contrasenya té moltes combinacions possibles, estem parlant d'ordres de magnitud com a 10¹⁰ possibilitats per a contrasenyes mitjanes.
Una clau SSH típica de 256 bits (com les de Ed25519) es mou en espais de cerca de l'ordre de 10⁶¹⁷ combinacions. A la pràctica, per a un atacant és matemàticament inviable endevinar una clau privada per força bruta amb ordinadors actuals.
Però és que a més el servidor ni tan sols es posa a calcular res si la clau pública presentada no és a authorized_keys. En aquest cas descarta la connexió gairebé immediatament, sense invocar PAM ni processos d'autenticació tradicionals, de manera que el consum de CPU durant un atac massiu és mínim.
Generar i comprovar claus SSH al client
Abans de tocar el servidor, comproveu si la vostra màquina ja té un parell de claus SSH generat. Només cal llistar el contingut de ~/.ssh:
ls -l ~/.sshSi veus fitxers tipus id_ed25519 i id_ed25519.pub o id_rsa i id_rsa.pub, ja tens un parell vàlid. Ed25519 és més modern i lleuger, així que sol ser la millor opció avui dia.
Si no tens claus, en genera unes de noves amb:
ssh-keygen -t ed25519 -C "tu_usuario@tu_equipo"L'ordre crearà dos fitxers:
- id_ed25519: la clau privada, que mai no has de compartir.
- id_ed25519.pub: la clau pública, que sí que pots copiar als servidors.
Pots veure el contingut de la clau pública amb:
cat ~/.ssh/id_ed25519.pubCopiar la clau pública al servidor i provar-hi accés
Al servidor, assegureu-vos que hi ha el directori ~/.ssh per a l'usuari amb què entrareu (per exemple, git o el vostre usuari administrador) i que teniu permisos 700:
mkdir -p ~/.ssh
chmod 700 ~/.sshDesprés afegeix el contingut del teu id_ed25519.pub del client a ~/.ssh/authorized_keys (creant el fitxer si no existeix) i dóna permisos 600:
echo "TU_PUBLIC_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keysRecorda reemplaçar TU_PUBLIC_KEY per la línia completa que has vist amb cat a la teva màquina. A partir d'aquí pots provar la connexió indicant la clau explícitament si vols:
ssh -i ~/.ssh/id_ed25519 usuario@IP_DEL_SERVIDORSi tot està bé, el servidor no et demanarà contrasenya i saltaràs directament a l'intèrpret d'ordres. En aquest punt ja estàs a punt per plantejar-te desactivar l'autenticació per contrasenya.
Desactivar completament PasswordAuthentication al servidor
Un cop verificat que pots accedir amb la teva clau des d'almenys un equip (idealment dos, per si en perds un), és bona idea desactivar el login per contrasenya per a SSH. Així curtes darrel tot intent de força bruta clàssic.
Abans de tocar la configuració, convé veure quins fitxers estan definint PasswordAuthentication, perquè en moltes instal·lacions modernes hi ha fitxers .d que sobreescriuen el valor del sshd_config principal:
sudo grep -R "PasswordAuthentication" /etc/ssh/És freqüent trobar alguna cosa com:
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes
/etc/ssh/sshd_config:PasswordAuthentication noEn aquest cas, la configuració efectiva serà yes perquè el fitxer 50-cloud-init.conf es carrega després i sobreescriu el valor. Pots comprovar el resultat final que està aplicant sshd amb:
sudo sshd -T | grep passwordauthenticationPer desactivar les contrasenyes de debò, edita el fitxer responsable (per exemple /etc/ssh/sshd_config.d/50-cloud-init.conf) i deixa:
PasswordAuthentication noDesprés reinicieu el servei SSH:
sudo systemctl restart sshI torna a verificar amb:
sudo sshd -T | grep passwordauthenticationSi torna «no», els intents de login amb contrasenya seran rebutjats immediatament. Programes com PuTTY mostraran un error en no poder oferir credencials de tipus password, però els teus clients amb claus continuaran funcionant sense cap problema.
Combinant claus SSH amb Fail2ban i altres mesures
Quan treus PasswordAuthentication de l'equació, el valor de Fail2ban per a SSH es torna més auxiliar que crític, ja que els bots no tenen ni tan sols camp on introduir la contrasenya. Tot i així, és recomanable mantenir la jail de sshd activa perquè serveix com a capa addicional davant intents rars d'altres tipus o mal ús de claus.
Si a aquest combo de només claus SSH + Fail2ban + bloqueig de root + llistes AllowUsers/AllowGroups ben afinades li sumes un firewall restrictiu (iptables/nftables, UFW, firewalld) i, si escau, llistes de control d'accés amb TCP Wrappers, hauràs portat la probabilitat d'intrusió per força bruta a un nivell ínfim.
En entorns encara més sensibles, podeu anar un pas més enllà i introduir autenticació de doble factor (2FA) per a SSH, usant mòduls com Google Authenticator o similars via PAM, o fins i tot restringir qui pot arribar al port de SSH mitjançant VPNs dedicades.
Amb tots aquests elements ben integrats —detecció d'intents en logs, configuració acurada de sshd, ús extensiu de Fail2ban, claus SSH en lloc de contrasenyes i, quan calgui, controls per IP—, un servidor Linux pot suportar sense despentinar-se els atacs de força bruta continus a SSH i altres serveis exposats, mantenint alhora un accés còmode i segur per als administradors.