Teoria del Servei de Transferència de Fitxers

1. Introducció: Per què existeix FTP i quin problema resol?

Abans de parlar dels protocols en si, és important entendre el context i la necessitat que va donar lloc a la creació de FTP. Als inicis de les xarxes informàtiques, als anys 70, els investigadors i tècnics es van trobar amb un problema fonamental: necessitaven una manera estandarditzada i fiable de transferir arxius entre ordinadors diferents, amb sistemes operatius diferents, connectats a través d'una xarxa.

Imagina't la situació: tens un ordinador amb informació important i necessites enviar aquesta informació a un altre ordinador que pot estar a l'altra punta del país. No hi ha USB, no hi ha correu electrònic tal com el coneixem avui, i cada sistema té les seves pròpies convencions per emmagatzemar i organitzar arxius. Aquesta era la realitat dels primers dies d'Internet (llavors anomenada ARPANET).

El File Transfer Protocol (FTP) va néixer com a solució a aquest problema. La primera especificació va aparèixer el 1971 en el RFC 114, però la versió que encara s'utilitza com a base avui dia es va estandarditzar el 1985 en el RFC 959. Aquest document, publicat per Jon Postel i Joyce Reynolds, va definir les regles que encara regeixen el funcionament bàsic de FTP més de 35 anys després.

2. Arquitectura i Funcionament Bàsic de FTP

2.1 El model client-servidor de FTP

FTP funciona segons el model client-servidor, però amb una particularitat única que el diferencia de la majoria de protocols que coneixem: utilitza dues connexions TCP separades i simultànies. Aquesta és una característica fonamental que cal entendre bé perquè condiciona tot el funcionament del protocol.

La primera connexió s'anomena canal de control (control connection) i s'utilitza per enviar ordres i rebre respostes. Quan tu, com a client, vols llistar els arxius d'un directori, descarregar un fitxer o canviar de carpeta, aquestes ordres viatgen pel canal de control. Aquest canal s'estableix quan el client connecta al port 21 del servidor i es manté obert durant tota la sessió FTP.

La segona connexió s'anomena canal de dades (data connection) i s'utilitza exclusivament per transferir el contingut dels arxius o els llistats de directoris. Aquesta connexió no està sempre oberta, sinó que s'estableix quan cal transferir dades i es tanca quan la transferència finalitza. Tradicionalment, aquesta connexió utilitzava el port 20 del servidor en mode actiu.

Doble camí

Aquesta separació té un motiu històric i pràctic: permet que les ordres i les dades viatgin per canals diferents, facilitant el control del procés de transferència. Per exemple, pots enviar una ordre per cancel·lar una descàrrega pel canal de control mentre les dades encara estan fluint pel canal de dades.

AC0375/04/01 — Miniactivitat

RA4 · CA4a

Captura amb Wireshark una sessió FTP completa (connexió, login i una transferència). Identifica el canal de control (port 21) i el canal de dades, i localitza en text pla les ordres USER i PASS — comprova que la contrasenya és perfectament llegible.

2.2 Mode actiu: el funcionament original

Quan FTP es va dissenyar als anys 70, Internet era molt diferent de com la coneixem avui. Els firewalls no existien tal com els coneixem, i el concepte de NAT (Network Address Translation) encara estava lluny de ser necessari. En aquest context, es va dissenyar el mode actiu, que funciona de la següent manera:

Primer, el client estableix la connexió de control amb el servidor al port 21. Això és senzill i funciona com qualsevol altra connexió: el client inicia la connexió cap al servidor. Fins aquí, tot normal.

Ara ve la part peculiar del mode actiu: quan cal transferir dades, el client no connecta directament al servidor per rebre-les. En lloc d'això, el client obre un port al seu propi ordinador i li diu al servidor: "Escolta, he obert el port 1234 al meu ordinador, quan vulguis enviar-me dades, connecta't tu a aquest port". El client envia aquesta informació mitjançant l'ordre PORT pel canal de control.

sequenceDiagram
    participant Client as Client FTP<br/>(IP: 192.168.1.100)
    participant Server as Servidor FTP<br/>(IP: 192.168.1.50)

    Note over Client,Server: FASE 1: Establiment del Canal de Control

    Client->>Server: SYN (Connexió TCP al port 21)
    Server->>Client: SYN-ACK
    Client->>Server: ACK
    Note over Client,Server: Canal de control establert al port 21

    Server->>Client: 220 Benvingut al servidor FTP
    Client->>Server: USER usuari
    Server->>Client: 331 Contrasenya requerida
    Client->>Server: PASS contrasenya
    Server->>Client: 230 Usuari autenticat

    Note over Client,Server: FASE 2: Preparació del Canal de Dades (MODE ACTIU)

    Note over Client: El client obre el port 1234<br/>i espera connexió del servidor

    Client->>Server: PORT 192,168,1,100,4,210
    Note over Client,Server: (El client comunica: connecta't a 192.168.1.100:1234)

    Server->>Client: 200 Comanda PORT acceptada

    Note over Client,Server: FASE 3: Sol·licitud de Transferència

    Client->>Server: LIST (per llistar fitxers)
    Server->>Client: 150 Obrint connexió de dades

    Note over Client,Server: FASE 4: Connexió de Dades (EL SERVIDOR INICIA)

    Note over Server: El servidor INICIA la connexió<br/>des del seu port 20 cap al<br/>port 1234 del client

    Server->>Client: SYN (Des del port 20 al port 1234 del client)
    Note over Client,Server: ⚠️ PROBLEMA: Molts firewalls bloquegen<br/>aquesta connexió entrant al client

    Client->>Server: SYN-ACK
    Server->>Client: ACK

    Note over Client,Server: Canal de dades establert

    Server->>Client: [Dades del llistat de fitxers]
    Server->>Client: [Més dades...]

    Note over Server: El servidor tanca la connexió<br/>de dades quan acaba

    Server->>Client: FIN
    Client->>Server: ACK

    Server->>Client: 226 Transferència completada

    Note over Client,Server: El canal de control roman obert<br/>per a futures comandes

El servidor, obedient, inicia una nova connexió des del seu port 20 cap al port que el client li ha indicat, i per aquesta nova connexió comencen a fluir les dades. Aquest és el comportament "actiu": el servidor s'activa i connecta activament cap al client.

Aquest disseny tenia sentit als anys 70 i 80, però es va convertir en un problema greu quan van aparèixer els firewalls i el NAT als anys 90. Pensa-ho bé: si tens un ordinador darrere d'un router amb NAT (com és el cas de pràcticament tots els usuaris domèstics i de moltes empreses), el teu ordinador té una IP privada (com 192.168.1.100) que no és accessible des d'Internet. Quan el client FTP diu al servidor "connecta't al meu port 1234", el servidor intenta connectar-se a una IP privada que no pot arribar, i la connexió falla.

A més, els firewalls estan configurats per bloquejar les connexions entrants no sol·licitades per raons de seguretat. Quan el servidor FTP intenta connectar al client, el firewall veu això com un intent de connexió externa no autoritzada i la bloqueja.

2.3 Mode passiu: la solució moderna

Per resoldre els problemes del mode actiu, es va desenvolupar el mode passiu (PASV) definit al RFC 1579 (1994). Aquest mode inverteix la lògica: ara és sempre el client qui inicia ambdues connexions.

sequenceDiagram
    participant Client as Client FTP<br/>(IP: 192.168.1.100)<br/>(Darrere NAT/Firewall)
    participant Firewall as Firewall/NAT<br/>del Client
    participant Server as Servidor FTP<br/>(IP: 203.0.113.50)<br/>(IP Pública)

    Note over Client,Server: FASE 1: Establiment del Canal de Control

    Client->>Firewall: SYN (Connexió TCP al port 21)
    Firewall->>Server: SYN (amb IP traduïda per NAT)
    Server->>Firewall: SYN-ACK
    Firewall->>Client: SYN-ACK
    Client->>Firewall: ACK
    Firewall->>Server: ACK

    Note over Client,Server: ✓ Canal de control establert al port 21<br/>El firewall recorda aquesta connexió

    Server->>Client: 220 Benvingut al servidor FTP
    Client->>Server: USER usuari
    Server->>Client: 331 Contrasenya requerida
    Client->>Server: PASS contrasenya
    Server->>Client: 230 Usuari autenticat

    Note over Client,Server: FASE 2: Negociació del Mode Passiu

    Client->>Server: PASV
    Note over Client,Server: El client demana que el servidor<br/>entri en mode passiu

    Note over Server: El servidor obre un port aleatori<br/>(exemple: port 51234)<br/>i espera que el CLIENT connecti

    Server->>Client: 227 Entering Passive Mode (203,0,113,50,200,18)
    Note over Client,Server: El servidor comunica:<br/>"He obert el port 51234 (200×256+18)<br/>a la IP 203.0.113.50, connecta't aquí"

    Note over Client: El client ara sap exactament<br/>on ha de connectar per<br/>al canal de dades

    Note over Client,Server: FASE 3: Sol·licitud de Transferència

    Client->>Server: LIST (per llistar fitxers)
    Server->>Client: 150 Obrint connexió de dades al port 51234

    Note over Client,Server: FASE 4: Connexió de Dades (EL CLIENT INICIA)

    Note over Client: ✓ El CLIENT inicia la connexió<br/>cap al port 51234 del servidor<br/>(connexió sortint, sense problemes!)

    Client->>Firewall: SYN (cap a 203.0.113.50:51234)
    Note over Firewall: El firewall veu una connexió SORTINT<br/>iniciada pel client → LA PERMET

    Firewall->>Server: SYN (amb IP traduïda per NAT)
    Server->>Firewall: SYN-ACK
    Firewall->>Client: SYN-ACK
    Client->>Firewall: ACK
    Firewall->>Server: ACK

    Note over Client,Server: ✓ Canal de dades establert<br/>sense problemes de firewall!

    Server->>Firewall: [Dades del llistat de fitxers]
    Firewall->>Client: [Dades traduïdes]
    Server->>Firewall: [Més dades...]
    Firewall->>Client: [Més dades...]

    Note over Server: El servidor tanca la connexió<br/>de dades quan acaba

    Server->>Firewall: FIN
    Firewall->>Client: FIN
    Client->>Firewall: ACK
    Firewall->>Server: ACK

    Server->>Client: 226 Transferència completada

    Note over Client,Server: ✓ El canal de control roman obert<br/>per a futures comandes PASV

    Note over Client,Server: AVANTATGES DEL MODE PASSIU:<br/>✓ El client inicia TOTES les connexions<br/>✓ Els firewalls permeten connexions sortints<br/>✓ NAT funciona correctament<br/>✓ No cal configurar port forwarding<br/>✓ És el mode estàndard des dels anys 90

El funcionament és el següent: després d'establir el canal de control, quan cal transferir dades, el client envia l'ordre PASV al servidor. El servidor respon obrint un port aleatori (normalment en el rang 1024-65535, configurable) i comunicant al client quin port ha obert. Per exemple, el servidor podria respondre: "He obert el port 5234, connecta't aquí".

Ara el client, que ja ha iniciat amb èxit la primera connexió, pot iniciar també la segona connexió cap al port que el servidor li ha indicat. D'aquesta manera, ambdues connexions són iniciades pel client, cosa que evita tots els problemes amb firewalls i NAT.

El mode passiu s'ha convertit en l'estàndard de facto per a connexions FTP modernes. Pràcticament tots els clients FTP actuals utilitzen mode passiu per defecte, i és el que recomanaries sempre per a connexions a través d'Internet.

AC0375/04/02 — Miniactivitat

RA4 · CA4a, CA4f, CA4g, CA4h, CA4i

Amb un client FTP gràfic (per exemple FileZilla), connecta't a un servidor forçant primer mode actiu i després mode passiu (opció de configuració del client). Captura amb Wireshark ambdues connexions i compara quin equip inicia el canal de dades en cada cas, i per què el mode actiu falla si el client és darrere de NAT.

3. El problema crític de seguretat de FTP

Ara que entenem com funciona FTP a nivell tècnic, cal parlar del seu problema més greu: la manca total de seguretat. Quan FTP es va dissenyar als anys 70, la seguretat no era una preocupació principal. Internet era una xarxa d'investigació utilitzada per universitats i centres de recerca que es confiaven mútuament.

El problema és que FTP transmet tot en text pla. I quan dic tot, vull dir absolutament tot: el nom d'usuari, la contrasenya, els noms dels arxius que transfereixes, i el contingut complet dels arxius. Qualsevol persona que pugui interceptar el tràfic de xarxa (mitjançant tècniques com sniffing o man-in-the-middle) pot veure tota aquesta informació tan clarament com si estigués llegint un document de text.

Per il·lustrar la gravetat d'això, imagina que ets un administrador de sistemes i et connectes al teu servidor FTP des d'un cafè amb WiFi pública. En el moment que introdueixes el teu nom d'usuari i contrasenya, qualsevol persona amb un portàtil i eines gratuïtes com Wireshark pot capturar aquests paquets i veure les teves credencials. No cal ser un hacker expert, només cal conèixer les eines bàsiques de xarxa que probablement ja ensenyes als teus alumnes.

A més, si estàs transferint documents confidencials, informes financers, o qualsevol altre tipus d'informació sensible, tot això viatja sense cap tipus de xifrat. És com enviar una postal en lloc d'una carta en un sobre: qualsevol que la intercepti pot llegir el contingut.

Aquest problema era tolerable als anys 80, però es va convertir en totalment inacceptable a mesura que Internet es va obrir al públic i va començar a utilitzar-se per a transaccions comercials i transferència de dades sensibles als anys 90.

4. FTPS: Afegint seguretat mitjançant TLS/SSL

4.1 La solució: xifrar FTP amb TLS

La primera solució que es va desenvolupar per resoldre els problemes de seguretat de FTP va ser FTPS (FTP Secure), també conegut com FTP/SSL o FTP/TLS. La idea era senzilla però efectiva: agafar el protocol FTP que ja coneixíem i funcionava, i afegir-hi una capa de xifrat utilitzant SSL (Secure Sockets Layer) o la seva evolució, TLS (Transport Layer Security).

El concepte és similar al que es va fer amb HTTP per crear HTTPS. De fet, TLS és el mateix protocol de xifrat que utilitza el teu navegador quan veus el candau a la barra d'adreces. La definició formal de FTPS va arribar amb el RFC 2228 el 1997 i posteriorment amb el RFC 4217 el 2005, que va clarificar molts aspectes de la implementació.

4.2 FTPS Explícit (FTPES): començant sense xifrar

Hi ha dues maneres d'implementar FTPS, i la primera és el mode explícit, també anomenat FTPES o Explicit FTPS. Aquest mode és molt intel·ligent en el seu disseny perquè manté la compatibilitat amb clients FTP antics mentre ofereix seguretat als clients moderns.

El funcionament és el següent: el client comença connectant al port 21 estàndard de FTP, exactament igual que faria un client FTP tradicional. Inicialment, aquesta connexió no està xifrada. Però abans de començar a enviar dades sensibles, el client envia una ordre especial anomenada AUTH TLS o AUTH SSL (depenent de la implementació). Aquesta ordre li diu al servidor: "Hola, jo suporto xifrat TLS, vols actualitzar aquesta connexió a una connexió segura?".

Si el servidor suporta FTPS, respon positivament i comença el procés anomenat TLS handshake (encaixada de mans TLS). Durant aquest procés, que dura només uns segons, passa el següent:

El servidor envia el seu certificat digital al client. Aquest certificat és com el DNI del servidor, una credencial emesa per una autoritat certificadora (CA) que demostra que el servidor és qui diu ser. El client verifica aquest certificat comprovant que està signat per una CA de confiança, que no ha caducat, i que el nom del servidor coincideix amb el del certificat.

Un cop verificat el certificat, el client i el servidor negocien quin algorisme de xifrat utilitzaran (per exemple, AES-256) i estableixen les claus de sessió que utilitzaran per xifrar tota la comunicació posterior. Aquest procés utilitza criptografia asimètrica (claus públiques i privades) per intercanviar de manera segura una clau simètrica que s'utilitzarà per xifrar les dades reals.

Després d'aquest handshake, tota la comunicació pel canal de control està xifrada. Quan el client envia el seu nom d'usuari i contrasenya, viatgen completament xifrats. Quan s'estableix el canal de dades, també es pot xifrar (de fet, és altament recomanable fer-ho).

L'avantatge d'aquest mode explícit és que si un client FTP antic, que no suporta TLS, intenta connectar al mateix servidor, pot fer-ho perfectament. Simplement no enviarà l'ordre AUTH TLS i la connexió continuarà sent FTP tradicional no xifrat. Això permet una migració gradual dels sistemes.

4.3 FTPS Implícit: xifrat des del primer moment

La segona manera d'implementar FTPS és el mode implícit, també anomenat Implicit FTPS. Aquest mode és més radical en la seva aproximació a la seguretat: el xifrat no és opcional ni es negocia, sinó que està sempre activat des del primer byte que s'envia.

En mode implícit, el servidor escolta en un port diferent, típicament el port 990 en lloc del 21. Quan un client connecta a aquest port, s'assumeix automàticament que vol una connexió xifrada, i el TLS handshake comença immediatament, abans fins i tot d'enviar qualsevol ordre FTP.

Aquest mode és més segur en el sentit que no hi ha cap moment en què la comunicació no estigui xifrada, però té un inconvenient important: un client FTP tradicional no pot connectar d'aquesta manera. Si intentes connectar amb un client que no suporta TLS al port 990, la connexió fallarà immediatament perquè el client esperarà un missatge FTP en text pla i rebrà dades xifrades que no podrà entendre.

Per aquest motiu, el mode implícit és menys utilitzat avui dia. La majoria d'implementacions modernes prefereixen el mode explícit perquè ofereix més flexibilitat mantenint un bon nivell de seguretat.

4.4 Versions de TLS i consideracions de seguretat

És important que entengueu que no tots els xifrats són iguals, i que la tecnologia evoluciona constantment. SSL, el protocol original, té versions SSL 2.0 i SSL 3.0 que avui es consideren completament insegures i no s'haurien d'utilitzar mai.

TLS és l'evolució de SSL i té diverses versions:

TLS 1.0 (1999): Obsolet, vulnerable a diversos atacs, no recomanat
TLS 1.1 (2006): Obsolet, ja no suportat pels navegadors moderns
TLS 1.2 (2008): Encara àmpliament utilitzat i considerat segur si es configura correctament
TLS 1.3 (2018): La versió més moderna i segura, més ràpida i amb millor criptografia

Configuracions correctes

Quan configuris un servidor FTPS el 2024-2025, hauries de desactivar SSL completament i només permetre TLS 1.2 o superior, idealment TLS 1.3. Moltes eines de compliance i auditories de seguretat marcaran com a vulnerabilitat qualsevol servidor que encara accepti connexions SSL o TLS 1.0/1.1.

5. SFTP: Un protocol completament diferent

5.1 La confusió del nom

Abans de res, cal aclarir una confusió molt comú que fins i tot professionals experimentats tenen de vegades: SFTP no és FTP amb seguretat afegida. Malgrat que el nom "SSH File Transfer Protocol" pugui fer pensar que és una variant de FTP, en realitat és un protocol completament diferent que no té gairebé res a veure amb FTP tret de la funció que compleix (transferir arxius).

Aquesta confusió és comprensible perquè tant FTPS com SFTP intenten resoldre el mateix problema (la inseguretat de FTP), però ho fan de maneres radicalment diferents. FTPS agafa FTP i hi afegeix xifrat, mantenint la lògica i l'estructura original. SFTP, en canvi, va ser dissenyat des de zero com part de l'ecosistema SSH.

5.2 SSH: el fonament de SFTP

Per entendre SFTP, primer cal entendre SSH (Secure Shell). SSH es va desenvolupar el 1995 per Tatu Ylönen com a reemplaçament segur per a protocols antics com telnet, rlogin i rsh, que, igual que FTP, transmetien tot en text pla.

SSH és molt més que un simple protocol de terminal remot. És un protocol de xifrat i autenticació robust que pot encapsular diferents tipus de comunicacions. Quan et connectes a un servidor Linux via SSH, estàs utilitzant SSH per obtenir una sessió de terminal, però SSH pot fer molt més: pot crear túnels xifrats, redirigir ports, i, el que ens interessa aquí, transferir arxius.

SSH funciona sempre pel port 22 i estableix una única connexió xifrada entre client i servidor. Dins d'aquesta connexió xifrada, pot haver-hi múltiples canals (channels) que transporten diferents tipus de dades: un canal per la sessió de terminal, un altre per cada fitxer que s'està transferint, un altre per cada port que s'està redirigint, etc.

Les especificacions de SSH estan definides en diversos RFCs, principalment els RFC 4251 a 4254 (2006). SFTP específicament està documentat com a "draft" (esborrany) de l'IETF, concretament el draft-ietf-secsh-filexfer, encara que mai no es va arribar a publicar com a RFC oficial. Tot i això, SFTP està àmpliament implementat i és un estàndard de facto.

5.3 Com funciona SFTP

SFTP funciona com un subsistema dins d'una connexió SSH. El procés és el següent:

sequenceDiagram
    participant Client as Client SFTP<br/>(IP: 192.168.1.100)<br/>(Darrere NAT/Firewall)
    participant Firewall as Firewall/NAT<br/>del Client
    participant Server as Servidor SSH<br/>(IP: 203.0.113.50)<br/>(Port 22)

    Note over Client,Server: FASE 1: Establiment de la Connexió SSH

    Client->>Firewall: SYN (Connexió TCP al port 22)
    Firewall->>Server: SYN (connexió sortint → PERMESA)
    Server->>Firewall: SYN-ACK
    Firewall->>Client: SYN-ACK
    Client->>Firewall: ACK
    Firewall->>Server: ACK

    Note over Client,Server: ✓ Connexió TCP establerta al port 22<br/>UNA SOLA CONNEXIÓ per a tot!

    Note over Client,Server: FASE 2: Negociació del Protocol SSH

    Server->>Client: SSH-2.0-OpenSSH_9.6
    Note over Server: El servidor anuncia la versió<br/>del protocol SSH que suporta

    Client->>Server: SSH-2.0-OpenSSH_9.6
    Note over Client: El client anuncia la seva versió<br/>i comproven compatibilitat

    Note over Client,Server: ✓ Ambdós utilitzen SSH Protocol 2<br/>(SSH-1 està obsolet i insegur)

    Note over Client,Server: FASE 3: Intercanvi de Claus (Key Exchange)

    Client->>Server: SSH_MSG_KEXINIT
    Note over Client: El client envia la llista d'algorismes<br/>que suporta per a xifratge, MAC,<br/>compressió i intercanvi de claus

    Server->>Client: SSH_MSG_KEXINIT
    Note over Server: El servidor respon amb els algorismes<br/>que suporta, i negocien quins utilitzar

    Note over Client,Server: Algorismes negociats (exemple):<br/>• Intercanvi claus: curve25519-sha256<br/>• Xifratge: aes256-gcm@openssh.com<br/>• MAC: hmac-sha2-512-etm@openssh.com<br/>• Compressió: none

    Client->>Server: SSH_MSG_KEX_ECDH_INIT
    Note over Client: El client envia la seva clau pública<br/>temporal per a l'intercanvi

    Server->>Client: SSH_MSG_KEX_ECDH_REPLY + Clau Host
    Note over Server: El servidor respon amb:<br/>• La seva clau pública temporal<br/>• La clau host del servidor (identitat)<br/>• Signatura digital de tot l'anterior

    Note over Client: El client verifica la clau host<br/>contra ~/.ssh/known_hosts<br/>Si és la primera connexió,<br/>demana confirmació a l'usuari

    Note over Client,Server: ✓ Claus de sessió generades<br/>✓ Identitat del servidor verificada<br/>A partir d'ara TOT està xifrat

    rect rgb(200, 255, 200)
        Note over Client,Server: === TOT EL TRÀFIC A PARTIR D'AQUÍ ESTÀ XIFRAT ===
    end

    Note over Client,Server: FASE 4: Autenticació del Client

    Client->>Server: SSH_MSG_USERAUTH_REQUEST (usuari: joan)
    Note over Client: El client demana autenticar-se<br/>i indica el mètode preferit

    Server->>Client: SSH_MSG_USERAUTH_FAILURE
    Note over Server: El servidor pot rebutjar alguns mètodes<br/>i indicar quins accepta

    alt Autenticació per Contrasenya
        Client->>Server: SSH_MSG_USERAUTH_REQUEST (password)
        Note over Client: ✓ La contrasenya viatja XIFRADA<br/>(a diferència de FTP)
        Server->>Client: SSH_MSG_USERAUTH_SUCCESS
    else Autenticació per Clau Pública (RECOMANAT)
        Client->>Server: SSH_MSG_USERAUTH_REQUEST (publickey)
        Note over Client: El client envia la seva clau pública<br/>i una signatura digital provant<br/>que posseeix la clau privada
        Server->>Client: SSH_MSG_USERAUTH_SUCCESS
        Note over Server: El servidor verifica que la clau pública<br/>està a ~/.ssh/authorized_keys<br/>i que la signatura és vàlida
    end

    Note over Client,Server: ✓ Client autenticat correctament

    Note over Client,Server: FASE 5: Obertura del Canal SFTP

    Client->>Server: SSH_MSG_CHANNEL_OPEN (session)
    Note over Client: El client demana obrir un canal<br/>dins de la connexió SSH existent

    Server->>Client: SSH_MSG_CHANNEL_OPEN_CONFIRMATION
    Note over Server: El servidor accepta i assigna<br/>un identificador al canal

    Client->>Server: SSH_MSG_CHANNEL_REQUEST (subsystem: sftp)
    Note over Client: El client demana iniciar<br/>el subsistema SFTP

    Server->>Client: SSH_MSG_CHANNEL_SUCCESS
    Note over Server: El servidor arrenca sftp-server<br/>i el connecta a aquest canal

    Note over Client,Server: ✓ Canal SFTP establert<br/>Un canal dins de la connexió SSH única

    Note over Client,Server: FASE 6: Operacions SFTP

    Client->>Server: SSH_FXP_INIT (versió SFTP: 3)
    Note over Client: El client inicia el protocol SFTP<br/>i indica quina versió suporta

    Server->>Client: SSH_FXP_VERSION (versió: 3, extensions)
    Note over Server: El servidor confirma la versió SFTP<br/>que utilitzaran (normalment v3)

    Client->>Server: SSH_FXP_REALPATH ("/")
    Note over Client: El client pregunta quin és<br/>el directori arrel real

    Server->>Client: SSH_FXP_NAME ("/home/joan")
    Note over Server: El servidor respon amb el path<br/>en el context del servidor

    Client->>Server: SSH_FXP_OPENDIR ("/home/joan")
    Note over Client: El client demana obrir un directori<br/>per llistar-ne el contingut

    Server->>Client: SSH_FXP_HANDLE (handle_id: 0x01)
    Note over Server: El servidor retorna un "handle"<br/>(identificador) per al directori

    Client->>Server: SSH_FXP_READDIR (handle: 0x01)
    Server->>Client: SSH_FXP_NAME (fitxers i directoris)
    Note over Server: El servidor envia la llista completa<br/>amb noms, permisos, mides, dates

    Client->>Server: SSH_FXP_CLOSE (handle: 0x01)
    Server->>Client: SSH_FXP_STATUS (OK)

    Note over Client,Server: Exemple: Descarregar un fitxer

    Client->>Server: SSH_FXP_OPEN ("document.txt", READ)
    Server->>Client: SSH_FXP_HANDLE (handle_id: 0x02)

    Client->>Server: SSH_FXP_READ (handle: 0x02, offset: 0, length: 32768)
    Server->>Client: SSH_FXP_DATA ([dades xifrades del fitxer])
    Note over Server: Les dades viatgen xifrades<br/>dins del canal SSH

    Client->>Server: SSH_FXP_READ (handle: 0x02, offset: 32768, length: 32768)
    Server->>Client: SSH_FXP_DATA ([més dades xifrades])

    Note over Client: El client pot sol·licitar múltiples<br/>blocs simultàniament per millorar<br/>el rendiment (pipelining)

    Client->>Server: SSH_FXP_READ (handle: 0x02, offset: 65536, length: 32768)
    Server->>Client: SSH_FXP_STATUS (EOF - End Of File)

    Client->>Server: SSH_FXP_CLOSE (handle: 0x02)
    Server->>Client: SSH_FXP_STATUS (OK)

    Note over Client,Server: ✓ Fitxer descarregat completament xifrat

    Note over Client,Server: FASE 7: Tancament de la Connexió

    Client->>Server: SSH_MSG_CHANNEL_CLOSE
    Server->>Client: SSH_MSG_CHANNEL_CLOSE

    Client->>Server: SSH_MSG_DISCONNECT
    Note over Client: El client tanca ordenadament<br/>la connexió SSH

    Server->>Client: SSH_MSG_DISCONNECT

    Client->>Firewall: FIN
    Firewall->>Server: FIN
    Server->>Firewall: ACK
    Firewall->>Client: ACK

    Note over Client,Server: ✓ Connexió tancada de manera segura

    Note over Client,Server: AVANTATGES CLAUS DE SFTP:<br/>✓ UNA SOLA connexió (port 22 únic)<br/>✓ TOT està xifrat des del primer byte<br/>✓ Autenticació robusta (claus públiques)<br/>✓ Cap problema amb firewalls/NAT<br/>✓ Suport natiu per a permisos Unix<br/>✓ Protocol modern i ben dissenyat<br/>✓ Integració perfecta amb SSH

Primer, el client estableix una connexió SSH estàndard amb el servidor al port 22. Aquest procés inclou:

Negociació de la versió del protocol SSH que s'utilitzarà (SSH-2 és l'estàndard modern, SSH-1 està obsolet)
Intercanvi de claus (key exchange): El client i el servidor acorden quin algorisme utilitzaran per xifrar la comunicació i generen les claus de sessió. Poden utilitzar algorismes moderns com Ed25519, ECDSA, o RSA.
Autenticació del servidor: El servidor presenta la seva clau pública (host key) al client. Si és la primera vegada que el client connecta a aquest servidor, demanarà confirmació a l'usuari i guardarà la clau per a futures connexions en el fitxer ~/.ssh/known_hosts. Això prevé atacs man-in-the-middle: si algú intenta fer-se passar pel servidor, la clau no coincidirà.
Autenticació del client: Aquí SSH ofereix més opcions que FTP/FTPS. Els dos mètodes principals són:
Autenticació per contrasenya: Similar a FTP, però la contrasenya viatja xifrada
Autenticació per clau pública: Molt més segura i recomanable. El client demostra que posseeix la clau privada corresponent a una clau pública que prèviament s'ha configurat al servidor

Un cop establerta la connexió SSH i autenticat l'usuari, el client demana iniciar el subsistema SFTP. El servidor SSH arrenca el servidor SFTP (normalment un programa anomenat sftp-server) i estableix un canal dins de la connexió SSH dedicat a les operacions d'arxius.

A partir d'aquest moment, totes les ordres i dades de SFTP viatgen per aquest canal xifrat dins de la connexió SSH. El client pot enviar ordres com llistar directoris, pujar arxius, descarregar arxius, canviar permisos, etc., i tot està xifrat amb el mateix nivell de seguretat que la resta de la sessió SSH.

5.4 Avantatges de SFTP sobre FTPS

SFTP té diversos avantatges significatius sobre FTPS que el fan més atractiu en molts escenaris:

Un sol port: SFTP només necessita el port 22. No hi ha connexions separades per control i dades, no hi ha ports aleatoris en mode passiu. Això simplifica enormement la configuració de firewalls i la travessia de NAT. Un administrador només ha de permetre el port 22, i punt.

Autenticació per clau pública: Encara que FTPS també pot utilitzar certificats de client, la pràctica habitual és utilitzar usuari i contrasenya. SFTP, en canvi, fa molt fàcil utilitzar autenticació per clau pública, que és molt més segura. Un cop configurat, el client pot connectar sense introduir contrasenya, utilitzant la seva clau privada (que a més pot estar protegida amb una passphrase).

Integració amb SSH: Si ja tens un servidor SSH configurat (cosa que és pràcticament universal en servidors Linux), SFTP funciona automàticament sense cap configuració addicional. No cal instal·lar ni configurar res extra. Els usuaris que ja poden accedir al servidor via SSH poden automàticament utilitzar SFTP.

Gestió de permisos Unix: SFTP entén i pot manipular els permisos de fitxers Unix (propietari, grup, permisos de lectura/escriptura/execució). Això el fa molt natural en entorns Linux/Unix.

Menys problemes amb firewalls: La naturalesa d'un sol port i connexió de SFTP fa que sigui molt més fàcil de fer funcionar a través de firewalls, proxies i NAT que FTPS, que amb les seves dues connexions i múltiples ports pot ser problemàtic.

Versió del protocol SFTP: La versió més comuna actualment és SFTP versió 3, suportada per OpenSSH des de la versió 2.3.0 (2001). Versions més recents d'OpenSSH (7.4+, 2016) suporten també SFTP versió 6, que afegeix algunes funcionalitats addicionals, encara que la versió 3 segueix sent la més àmpliament compatible.

6. Què s'utilitza avui dia?

FTP tradicional (sense xifrat) està pràcticament obsolet per a nous projectes: cap organització responsable amb la seguretat hauria d'utilitzar-lo per transferir dades a través d'Internet. FTPS encara es manté en alguns contextos puntuals (entorns Windows amb inversió prèvia en IIS, integracions EDI antigues, hostings compartits), però en la immensa majoria de casos nous s'imposen SFTP i alternatives que ja no tenen res a veure amb FTP.

Aquesta pàgina s'ha centrat en el protocol FTP i les seves variants directes (FTPS, SFTP). Per conèixer el ventall complet de sistemes que s'utilitzen avui dia per transferir fitxers —rsync, APIs REST, sincronització al núvol, MFT, etc.— consulta la pàgina Sistemes Moderns de Transferència de Fitxers.

Referències

RFCs, estàndards i informes sobre FTP/FTPS/SFTP: consulta la secció Servei de Transferència de Fitxers a la pàgina d'Annexos · Recursos.

Activitats

Pràctica 4.1 :Desplegament d'un Servei FTP Corporatiu amb Docker i vsftpd (CA4a,CA4b, CA4c,CA4d,CA4e,CA4f,CA4g,CA4h,CA4j)