Ja has fet servir SSH en aquest curs desenes de vegades: entres a srv-tramontana des de portatil-alumne, copies fitxers amb scp i sincronitzes amb rsync. L'has fet servir com qui fa servir un ascensor, sense preguntar-te com funciona. Aquesta lliçó obre la caixa, perquè SSH és la porta principal del teu servidor i en aquest moment aquella porta accepta contrasenyes, permet entrar com a root i porta acumulats 47 intents fallits des de 203.0.113.44 que ningú no ha mirat.

En acabar tindràs claus ed25519 en lloc de contrasenyes, un sshd_config enfortit directiva a directiva, un ~/.ssh/config que fa la feina pesada per tu, túnels per arribar a la base de dades de Tramontana sense exposar-la a ningú, i el costum —que aquí no és opcional— de no tancar mai la porta per la qual estàs entrant.

1. Què resol SSH i per què Telnet i FTP són morts
2. Arquitectura i les tres fases del protocol
3. Autenticació del servidor: claus d'amfitrió i known_hosts
4. Autenticació amb claus: generar, instal·lar i protegir
5. ssh-agent, reenviament d'agent i ProxyJump
6. El fitxer de configuració del client
7. Enfortir /etc/ssh/sshd_config
8. El procediment segur per no quedar-te fora
9. Túnels: local, remot i SOCKS
10. Transferència de fitxers: scp, sftp i rsync
11. Sessions persistents amb tmux
12. Auditoria: els 47 intents des de 203.0.113.44

Abans de SSH, administrar una màquina remota volia dir Telnet: un protocol que envia usuari, contrasenya i totes les ordres en text pla per la xarxa. Qualsevol amb accés al mateix segment —o a l'encaminador del mig— llegia la sessió sencera. El mateix amb FTP, rlogin i rsh.

SSH resol tres problemes alhora, i convé distingir-los perquè cadascun s'ataca de manera diferent:

La tercera és la que més s'oblida i la més important: un canal xifrat cap a l'atacant equivocat no protegeix absolutament res. Per això la lliçó dedica un apartat sencer a known_hosts.

A srv-tramontana hi corre el dimoni sshd, gestionat per systemd. A Ubuntu 24.04 hi ha un detall que sorprèn molta gent: el servei està activat per sòcol.

ssh.socket escolta el port i arrenca ssh.service quan arriba una connexió. La conseqüència pràctica és important i la reprenem a l'apartat 7: la directiva Port de sshd_config s'ignora mentre l'activació per sòcol estigui en marxa.

Una connexió SSH travessa tres fases en aquest ordre:

1. Intercanvi de claus i canal xifrat. Client i servidor negocien algorismes i deriven una clau de sessió amb Diffie-Hellman efímer. A partir d'aquí tot va xifrat, inclosa la fase 3.
2. Autenticació del servidor. El servidor demostra que posseeix la clau privada corresponent a la seva clau d'amfitrió; el client comprova aquella clau contra known_hosts.
3. Autenticació del client. Ara, i només ara, l'usuari s'identifica —amb clau o amb contrasenya—. És fonamental que vagi després: per això la contrasenya no viatja mai en clar.

El servidor té les seves pròpies claus a /etc/ssh/, generades en la instal·lació:

La primera vegada que t'hi connectes veus això:

Què significa de debò aquell avís, i no el que fa tothom: SSH t'està dient «no tinc manera de saber si aquesta màquina és la que busques». La resposta correcta no és teclejar yes a cegues, sinó comparar aquella empremta amb la que has obtingut per un canal diferent —la consola de la VM, el tauler del proveïdor de núvol, un correu signat de qui va instal·lar el servidor—. Si acceptes sense comprovar, acceptes la primera màquina que respongui, i aquest és exactament el forat de l'atac d'intermediari (man-in-the-middle): algú es col·loca entre tu i el servidor, et presenta la seva clau d'amfitrió, tu l'acceptes, i a partir d'aquí desxifra la teva sessió, veu la teva contrasenya i la reenvia al servidor real. Tot amb el cadenat verd posat.

Després d'acceptar, la clau es guarda a ~/.ssh/known_hosts i les connexions següents es verifiquen soles. Si un dia canvia, veuràs un avís enorme amb REMOTE HOST IDENTIFICATION HAS CHANGED! i la connexió es rebutja. Les causes legítimes són tres: es va reinstal·lar el servidor, es van regenerar les seves claus d'amfitrió, o la IP es va reutilitzar per a una altra màquina. La causa il·legítima és un intermediari. Esbrina quina és abans d'esborrar res, i quan ho sàpigues, esborra només aquella entrada:

Mai rm ~/.ssh/known_hosts: això destrueix la confiança acumulada amb totes les màquines i et deixa acceptant empremtes noves a cegues durant setmanes.

La criptografia asimètrica fa servir una parella de claus relacionades matemàticament: el que signa la privada només ho verifica la seva pública corresponent, i de la pública no se'n pot deduir la privada en un temps raonable. A SSH, tu guardes la privada al teu portàtil i puges la pública al servidor. Per autenticar-te, el servidor et llança un repte, tu el signes amb la privada i ell verifica la signatura amb la pública que té a authorized_keys. La clau privada no surt mai de la teva màquina, ni tan sols xifrada: això és el que la fa radicalment millor que una contrasenya, que sí que viatja (encara que sigui per un canal xifrat) i que sí que es pot endevinar a força d'intents.

Per què ed25519 i no RSA: ed25519 ofereix seguretat equivalent a RSA de 3072 bits amb claus de 68 caràcters, signa i verifica més ràpid, no depèn d'un generador de nombres aleatoris de qualitat en cada signatura i no té paràmetres que puguis triar malament. Fes servir RSA de 4096 bits només si necessites compatibilitat amb equipament antic que no admeti ed25519. El comentari -C no és decoratiu: identifica de qui i de quan és la clau quan revisis authorized_keys d'aquí a dos anys.

La frase de pas xifra la clau privada al disc. És la segona capa: si et roben el portàtil, tenen un fitxer inútil sense ella. El cost —teclejar-la en cada ús— el resol ssh-agent.

Els permisos són obligatoris, no una recomanació. SSH es nega a fer servir una clau privada llegible per altres:

Instal·lar la pública al servidor, amb l'eina o a mà:

Cada línia d'authorized_keys admet opcions per clau davant del tipus, i són una capa de control que gairebé ningú no fa servir:

La combinació restrict,command= és la manera correcta de donar accés a un procés automàtic —una còpia, un desplegament— sense donar-li una shell.

ssh-agent guarda la teva clau desxifrada a memòria per no teclejar la frase de pas cada vegada:

-t 4h fa que la clau caduqui a l'agent: si deixes el portàtil desbloquejat en una cafeteria, la finestra d'exposició és limitada. ssh-add -D les esborra totes de cop.

El reenviament d'agent (ssh -A) permet fer servir les teves claus des del servidor on has entrat, per saltar a un tercer. El seu risc real: mentre la sessió està oberta, qualsevol amb root en aquella màquina intermèdia pot fer servir el teu agent —parlar amb el sòcol de /tmp/ssh-*/agent.* i signar amb les teves claus per entrar a qualsevol lloc on valguin—. No et roba la clau, però la pot fer servir, que a efectes pràctics és el mateix.

L'alternativa correcta és ProxyJump, que no exposa l'agent: el client obre un túnel a través del salt i negocia el xifratge d'extrem a extrem amb la destinació final.

Regla pràctica: fes servir ProxyJump sempre; fes servir -A només si no hi ha alternativa, i llavors amb ssh-add -c (demana confirmació en cada ús).

Tot l'anterior s'escriu una vegada a ~/.ssh/config (permisos 600) i desapareix de la teva memòria muscular:

El multiplexatge és el que més es nota: rsync i scp repetits deixen de renegociar el xifratge cada vegada.

Aquest és el cor de la lliçó. Ubuntu 24.04 llegeix /etc/ssh/sshd_config i, a dins, un Include /etc/ssh/sshd_config.d/*.conf al principi del fitxer. Com que a SSH guanya el primer valor trobat, el que posis en un fitxer de sshd_config.d/ té prioritat sobre el fitxer principal. Aquesta és la manera neta d'enfortir sense tocar l'original ni barallar-te amb la propera actualització del paquet.

I el debat honest sobre canviar el port: moure SSH del 22 al 2222 redueix moltíssim el soroll dels escanejos automàtics i, per tant, la mida dels teus registres. El que no fa és protegir-te: qualsevol nmap de deu segons troba el port nou, i a canvi compliques la vida a les teves eines i als teus companys. És higiene de registres, no seguretat; no ho comptis mai com a control. Si tot i així ho fas a Ubuntu 24.04, recorda l'activació per sòcol: Port 2222 a sshd_config no té efecte i cal tocar el sòcol.

La primera línia buida esborra la llista heretada; sense ella, el servei escoltaria als dos ports.

La regla d'or d'aquest mòdul: no tanquis mai la porta per la qual estàs entrant. A SSH es tradueix en cinc passos que no se salten mai.

sshd -t valida la sintaxi; sshd -T et mostra el resultat després de resoldre els Include, que és l'únic que compta. reload rellegeix la configuració sense tocar les sessions establertes: si l'has espifiada, les teves dues sessions obertes continuen vives i pots revertir. I per damunt de tot hi ha la consola de la VM a VirtualBox, que no passa per la xarxa i és el teu últim recurs. Amb activació per sòcol, un canvi de port necessita a més sudo systemctl restart ssh.socket.

Un túnel SSH transporta una connexió TCP arbitrària dins del canal xifrat. Tres formes, tres casos d'ús reals a Tramontana:

Llegeix -L 15432:127.0.0.1:5432 així: «obre el port 15432 a la meva màquina; el que hi arribi, treu-ho per l'altre extrem del túnel i lliura-ho a 127.0.0.1:5432 vist des del servidor». És exactament el que necessites per administrar la base de dades amb una eina gràfica sense obrir el 5432 al tallafocs. -N significa «no executis cap ordre, només el túnel».

Avís important: per defecte els túnels remots (-R) només escolten a localhost del servidor, i això està bé. Obrir-los a totes les interfícies requereix GatewayPorts yes a sshd_config, que és una manera estupenda de saltar-te el teu propi tallafocs sense adonar-te'n. Deixa-ho tal com està.

--partial conserva el que s'ha transferit si la connexió es talla, i --progress et diu si val la pena esperar. Combinat amb el ControlPersist de l'apartat 6, un rsync repetit ni tan sols renegocia el xifratge.

Si la teva connexió es talla a mig apt upgrade o d'un desplegar.sh, el procés rep SIGHUP i mor a mitges. Un desplegament interromput entre l'rsync del release i el systemctl restart deixa l'aplicació en un estat que ningú no va dissenyar.

tmux (o screen, més antic) manté la sessió al servidor, independent de la teva connexió. Regla professional: tota operació llarga en producció es llança dins de tmux. És gratis i evita incidents dels que s'expliquen durant anys.

Tot el que fa sshd acaba al journal i a /var/log/auth.log.

lastb llegeix /var/log/btmp, el registre d'intents fallits (last llegeix wtmp, els correctes). Amb el que has après al Mòdul 3, el resum per IP i per usuari provat surt en una línia:

Interpretació: 47 intents des d'una sola IP, provant root, admin, postgres i ubuntu en tres minuts. No és algú que s'equivoqui de contrasenya: és un bot de força bruta, un dels milers que escombren Internet. Els dos intents des de 10.0.2.77 són de la xarxa interna i probablement siguin el Luis teclejant malament.

El bo: amb PasswordAuthentication no acabes de convertir aquells 47 intents en soroll inofensiu, perquè ja no existeix la via que estaven provant. El dolent: el bot continua trucant, consumeix recursos, embruta els teus registres i hi continuarà sent demà amb una altra tècnica. Bloquejar-lo a la porta —i automatitzar el bloqueig— és exactament la feina de la lliçó següent.

Advertiment de seguretat i compliment: srv-tramontana tracta dades personals d'hostes, així que l'accés remot és un control subjecte al RGPD. En un entorn real això implica accessos nominatius (mai comptes compartits), registre de qui entra i quan amb retenció acordada, revisió periòdica d'authorized_keys per retirar les claus de qui ja no hi és, i revisió del canvi pel responsable de seguretat. I l'anàlisi de registres d'accés, que identifica persones treballadores, té límits legals: es fa amb finalitat de seguretat i amb la política informada, no per vigilar ningú.

• Activar PasswordAuthentication no sense haver provat la clau. El clàssic que deixa gent fora de servidors en producció. Prova primer ssh -o PreferredAuthentications=publickey, i només aleshores recarrega.
• Permisos incorrectes a ~/.ssh. SSH ignora en silenci (o gairebé) claus i authorized_keys massa oberts. 700 el directori, 600 les claus privades i authorized_keys. Si alguna cosa «no funciona sense motiu», ssh -vvv t'ho diu a la línia Authentications that can continue.
• Esborrar known_hosts sencer davant d'un avís d'empremta canviada. Investiga la causa i fes servir ssh-keygen -R <amfitrió>.
• systemctl restart ssh en comptes de reload. Amb configuració trencada, restart et deixa fora; reload manté vives les sessions existents.
• Copiar la clau privada als servidors «per saltar d'un a l'altre». La privada no surt del teu portàtil: per això hi ha ProxyJump i, amb reserves, l'agent.
• Oblidar que el grup d'AllowGroups ha d'existir. Si escrius AllowGroups sshusers i el grup és buit, no hi entra ningú. Crea'l i afegeix-hi la gent abans de recarregar.
• Consell: documenta cada clau d'authorized_keys amb el seu comentari -C (persona, màquina, data) i revisa-ho cada trimestre. Una clau òrfena és una porta oberta amb nom oblidat.

1. Accés restringit per a les còpies. El NAS de Tramontana (10.0.2.90) ha d'executar, i només això, /home/operador/scripts/copia_tramontana.sh --nomes-lectura al servidor. Escriu la línia exacta d'authorized_keys i justifica'n cada opció.
2. Túnel a la base de dades. La Marta vol que el Luis consulti PostgreSQL des de portatil-luis amb una eina gràfica, sense que el 5432 quedi exposat. Dona l'ordre, explica'n cada paràmetre i digues què es configura a l'eina.
3. Recuperació d'un canvi desastrós. Apliques AllowGroups admins (grup inexistent) i recarregues. Tens una sessió SSH oberta i la consola de la VM. Detalla el diagnòstic i la reparació, i quin pas del procediment t'hauria estalviat el disgust.

1. Una sola línia, amb doble pany —qui i des d'on— més el confinament de l'ordre:

• from="10.0.2.90" — encara que robin la clau del NAS, només serveix des d'aquella IP. És una capa extra que no costa res.
• restrict — desactiva de cop túnels, reenviament d'agent, X11 i assignació de pty. És el valor per defecte segur: en lloc d'anar prohibint coses una a una, es prohibeix tot i s'habilita el necessari.
• command="..." — s'executa aquella ordre passi el que passi; si el NAS demana bash, obté igualment l'script. L'original queda a SSH_ORIGINAL_COMMAND, així que l'script el podria inspeccionar, però mai executar-lo a cegues.
• El comentari final identifica la clau per a la revisió trimestral.

Amb aquelles tres opcions, un compromís del NAS no et dona una shell a srv-tramontana: dona com a molt una còpia de només lectura executada des d'una IP concreta.

2. Un túnel local des del portàtil del Luis:

• -L 15432:127.0.0.1:5432 — obre el 15432 a portatil-luis; el que hi arribi surt pel túnel i es lliura a 127.0.0.1:5432 des del punt de vista del servidor. La base de dades continua escoltant només a localhost.
• -N — no executar cap ordre remota: només volem el túnel.
• -f — passar a segon pla un cop autenticat, per recuperar el terminal.

A l'eina gràfica, el Luis configura amfitrió 127.0.0.1, port 15432, el seu usuari i la seva base de dades. El que això protegeix: PostgreSQL no està exposat a la xarxa, l'autenticació la controla SSH (amb clau, no contrasenya) i el trànsit va xifrat. El que no protegeix: si el portàtil del Luis està compromès, l'atacant té el mateix accés; i qualsevol usuari local d'aquell portàtil pot fer servir el 15432, així que la forma estricta seria -L 127.0.0.1:15432:127.0.0.1:5432.

3. Diagnòstic i reparació des de la sessió que continua oberta (o des de la consola de la VM):

Dues reparacions possibles, segons el que volguessis fer:

El pas que t'hauria estalviat el disgust és el 3 del procediment: sudo sshd -T mostra la configuració efectiva, i comprovar getent group admins abans de recarregar hauria revelat en dos segons que el grup no existia. sshd -t no ho detecta, perquè la sintaxi és perfectament vàlida: el fitxer està ben escrit i diu exactament el que no volies. Aquesta és la diferència entre validar la sintaxi i validar la intenció — i la raó que la segona sessió oberta no sigui negociable.

La porta principal de srv-tramontana ja té pany. Has entès les tres fases del protocol i per què la contrasenya no viatja mai en clar; saps què significa de debò l'empremta que et demanen acceptar la primera vegada i com reaccionar quan canvia; tens una parella ed25519 amb frase de pas, un agent que la fa caducar a les quatre hores i un ~/.ssh/config que multiplexa connexions i salta amb ProxyJump en comptes d'exposar l'agent. Al servidor, un fitxer a sshd_config.d/ prohibeix root, elimina l'autenticació per contrasenya, restringeix l'accés al grup sshusers i registra en mode VERBOSE l'empremta de cada clau que entra — tot aplicat amb sshd -t, sshd -T, reload i tres sessions obertes, perquè mai no es tanca la porta per la qual estàs entrant. I arribes a la base de dades per un túnel -L sense exposar ni un sol port de més.

També has posat nom al soroll: 47 intents des de 203.0.113.44 provant root, admin, postgres i ubuntu en tres minuts. Contra aquella IP concreta has guanyat —ja no hi ha contrasenyes per endevinar—, però el bot continua tocant el timbre, i demà provarà el 8080, que continua obert de bat a bat a qualsevol que arribi a la màquina, igual que ho estaria PostgreSQL si algun dia escoltés fora de localhost. SSH era un servei; el que falta és una política de què pot arribar ni tan sols a parlar amb aquest servidor. Això és la lliçó 06-03: Tallafocs i Seguretat Perimetral, on coneixeràs netfilter i nftables per dins, aixecaràs ufw en l'ordre correcte per no perdre la sessió, escriuràs un conjunt de regles complet per a Tramontana, ajustaràs els sysctl de xarxa amb impacte en seguretat i posaràs fail2ban a bloquejar automàticament 203.0.113.44 i tots els que vinguin darrere.