FTP vs SFTP vs SCP: quando usare quale

Trasferire file da e verso un server e un compito quotidiano. FTP, SFTP e SCP sono tre protocolli ancora in uso, ma con caratteristiche molto diverse in termini di sicurezza, performance e ambito d'uso. Scegliere quello giusto e una questione di buona pratica, non di abitudine.

FTP: il protocollo legacy

FTP (File Transfer Protocol) e il più antico (1971), usa porte 20/21 e ha una doppia connessione (controllo e dati). Lo standard non cifra nulla: credenziali e file viaggiano in chiaro. Esistono varianti FTPS (FTP over SSL/TLS) che aggiungono cifratura ma mantengono la complessita delle porte multiple. Nel 2026 FTP puro e fortemente sconsigliato e i browser moderni l'hanno rimosso.

SFTP: il successore sicuro

SFTP (SSH File Transfer Protocol) NON e FTP cifrato: e un protocollo completamente diverso, parte della suite SSH. Usa una sola porta (22), cifrato end-to-end, autenticazione con password o chiave SSH. Stessi vantaggi e sicurezza di SSH. Disponibile su qualsiasi server con sshd, supporta operazioni avanzate (mkdir, chmod, resume). E lo standard moderno per trasferimento file.

SCP: trasferimento rapido

SCP (Secure Copy) e una utility CLI basata su SSH per copiare file singoli. Sintassi semplice: scp file.txt user@server:/path/. Storicamente molto usato, ma dal 2020 in disuso perché il protocollo SCP ha vulnerabilita strutturali. OpenSSH 9 ha deprecato il binario scp in favore di SFTP. Oggi scp usa internamente SFTP, quindi conviene usare direttamente sftp o rsync.

Confronto sintetico

• Cifratura: FTP no, FTPS si, SFTP si, SCP si.
• Porte: FTP 20/21 + range passivo, SFTP/SCP solo 22.
• Autenticazione: FTP password, SFTP password+chiave SSH.
• Resume: SFTP si, SCP no.
• Performance: SCP leggermente più rapido su singoli file; SFTP migliore per sessioni multiple.
• Tool: FileZilla, WinSCP, Cyberduck supportano tutti SFTP.

Quando usare cosa

• SFTP: scelta default per tutto.
• FTPS: solo se devi mantenere compatibilità con sistemi legacy che richiedono FTP.
• rsync over SSH: sincronizzazioni grandi, backup, mirror.
• FTP puro: mai (salvo eccezioni in reti chiuse e fidate).

Procedura passo-passo per migrare da FTP a SFTP

1. Verifica che sshd sia attivo sul server (lo e di default).
2. Crea utenti SFTP-only con ChrootDirectory e ForceCommand internal-sftp.
3. Limita i permessi: Subsystem sftp internal-sftp in sshd_config.
4. Disabilita FTP sul server: systemctl disable --now vsftpd.
5. Aggiorna i client: configura SFTP con porta 22 e credenziali SSH.
6. Migra le credenziali a chiavi SSH dove possibile.
7. Aggiorna script che usavano FTP (lftp ha modalita sftp).
8. Documenta la nuova procedura per il team.

Errori comuni e come risolverli

• Confondere FTPS e SFTP: sono protocolli diversi, una porta vs due.
• Permessi sbagliati in ChrootDirectory: deve essere root-owned con 755.
• Usare ancora FTP perché il client lo supporta: la password viene sniffata.
• Trasferimenti enormi senza resume: usa rsync per recuperare interruzioni.

Domande frequenti

D: I miei utenti possono usare FileZilla?
R: Si, supporta SFTP nativamente con sessioni chiave SSH.

D: Cosa usare per copie giganti?
R: rsync over SSH e ottimo (delta, resume, compressione).

D: FTPS e SFTP hanno performance simili?
R: SFTP e leggermente più lento su file singoli ma più robusto.

Approfondimento tecnico: chroot SFTP e rsync over SSH

Per dare accesso SFTP a utenti non fidati senza esporre l'intero filesystem, usa chroot SFTP. In sshd_config: Match Group sftponly, ChrootDirectory /home/%u, ForceCommand internal-sftp, AllowTcpForwarding no. La directory chroot deve essere posseduta da root con permessi 755; le subdirectory dell'utente possono essere scrivibili. L'utente vede la chroot come "/" e non puo uscirne.

rsync over SSH e la combinazione ideale per sincronizzazioni di file: trasferisce solo delta, supporta resume, comprime, preserva permessi e attributi estesi. Per trasferimenti automatici usa chiavi SSH dedicate con command="rsync --server ..." in authorized_keys, limitando il comando eseguibile dalla chiave.

Scenari d'uso reali

Un web designer aggiorna i siti dei clienti via SFTP da Cyberduck con chiavi SSH per evitare riportare password.

Un cron di backup usa rsync over SSH per replicare un dataset di 500 GB con delta giornalieri di pochi MB.

Un hosting condiviso da accesso SFTP chroot ai clienti, vietando shell login.

Checklist operativa trasferimento file

• FTP disabilitato, solo SFTP attivo.
• Utenti SFTP-only con ChrootDirectory.
• Chiavi SSH preferite alle password.
• rsync per sincronizzazioni grandi o incrementali.
• Limit di velocità per evitare saturazione banda.
• Logging trasferimenti per audit.
• Verifica integrita post-trasferimento.

Risorse e riferimenti

OpenSSH manuali. rsync.samba.org. Client GUI: FileZilla, WinSCP, Cyberduck, Transmit. Per scripting: lftp con backend sftp, paramiko Python. Audit trasferimenti: log sshd in /var/log/auth.log con dettaglio sftp.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su ftp vs sftp vs scp richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.