SFTP o FTP per WordPress: passare alle chiavi SSH

Aprire nel pannello di hosting la pagina degli account FTP: su molti siti WordPress si troverà almeno un accesso che nessuno sa spiegare. Può risalire all'agenzia che ha realizzato il sito, a un freelance che tre anni fa ha sistemato un plugin, oppure essere un account di prova chiamato ftp1. Sul confronto tra SFTP e FTP la risposta è semplice: eliminare quegli account, smettere di usare l'FTP in chiaro e assegnare a ogni persona una propria chiave SSH per SFTP. Questa guida descrive il passaggio in un ordine che non lascia nessuno fuori dal server.

SFTP o FTP: perché l'FTP in chiaro va abbandonato

L'FTP in chiaro trasmette nome utente, password e ogni file senza cifratura. Chiunque si trovi lungo il percorso di rete può leggere tutto: per esempio sul Wi-Fi di un albergo, attraverso un router d'ufficio compromesso o presso un operatore di rete poco attento. Rientra qui anche wp-config.php con la password del database, se mai lo si è scaricato via FTP.

Gli accessi FTP, inoltre, stanno del tutto fuori da WordPress. L'autenticazione a due fattori su wp-admin non li protegge e non compaiono nell'elenco degli utenti WordPress. Chi dispone di una password FTP valida può caricare un file PHP ed eseguire codice sul sito senza mai vedere la pagina di login.

Cambiare protocollo ha limiti precisi. SFTP non serve se il portatile che custodisce la chiave è infetto e non risolve il problema di un plugin vulnerabile. Chiude una porta ben definita: credenziali leggibili e accessi dimenticati al file system.

FTP, FTPS e SFTP a confronto

I nomi creano confusione, quindi ecco la versione breve.

FTPS è il vecchio protocollo FTP avvolto in TLS. Cifra il traffico, ma apre comunque connessioni dati separate, che spesso entrano in conflitto con firewall e NAT: il risultato è il classico errore «recupero elenco directory non riuscito». SFTP, nonostante il nome, non ha nulla a che vedere con l'FTP. È un sottosistema di SSH, funziona su un'unica connessione cifrata e consente l'accesso con chiavi SSH al posto delle password.

La nostra raccomandazione: usare SFTP se l'host offre l'accesso SSH, FTPS solo come ripiego e l'FTP in chiaro mai. In FileZilla il protocollo si imposta nel Gestore siti su «SFTP - SSH File Transfer Protocol». Se si deve usare FTPS, scegliere «Require explicit FTP over TLS» (le voci sono quelle dell'interfaccia in inglese). Non scegliere «Use explicit FTP over TLS if available», perché questa opzione ripiega in silenzio sull'FTP in chiaro quando TLS non funziona. WinSCP offre la stessa scelta alla voce «File protocol».

Prima di tutto: trovare ed eliminare i vecchi account FTP

Si parte da un inventario, prima di creare qualsiasi chiave. Dove guardare:

• La sezione account FTP del pannello di hosting (cPanel, Plesk e pannelli simili ne hanno una).
• La sezione accesso SSH o chiavi SSH, comprese le chiavi già autorizzate.
• Sul proprio server: gli utenti di sistema con una shell di login (grep -vE 'nologin|false' /etc/passwd) e ogni file ~/.ssh/authorized_keys.

Per ogni account si annota chi lo usa e a che scopo. Se nessuno sa indicarne il titolare, l'account va eliminato: cambiargli la password non basta. Se la password dell'account di hosting principale è stata digitata anche una sola volta in un client FTP, va cambiata pure quella, perché ha viaggiato almeno una volta senza cifratura.

Conviene tenere una breve registrazione della pulizia: data, account rimossi, chi l'ha approvata. La stessa verifica va fatta in parallelo sugli accessi a WordPress; la nostra guida alla sicurezza dei ruoli utente di WordPress tratta questo aspetto.

Generare una chiave SSH con passphrase (una per persona)

Ogni persona crea la propria chiave sul proprio computer. macOS, Linux e le versioni attuali di Windows includono OpenSSH:

ssh-keygen -t ed25519 -C "anna@example-company.eu"

Si accetta il percorso predefinito e, alla richiesta, si imposta una passphrase. Non saltare la passphrase. Il comando crea due file:

• ~/.ssh/id_ed25519 è la chiave privata. Non lascia mai il dispositivo.
• ~/.ssh/id_ed25519.pub è la chiave pubblica. È quella da condividere.

Per non digitare la passphrase a ogni connessione, si carica la chiave una volta per sessione in un agent con ssh-add ~/.ssh/id_ed25519. Su Windows occorre prima attivare il servizio «OpenSSH Authentication Agent». Alcuni client, come PuTTY, richiedono il formato .ppk: PuTTYgen può importare la chiave OpenSSH e salvarne una copia .ppk. Il manuale di ssh-keygen elenca tutte le opzioni.

Perché una chiave per persona? Revocare l'accesso a qualcuno significa allora cancellare una sola riga, e i log mostrano quale chiave è stata usata. Con chiavi e login condivisi entrambe le cose sono impossibili, quindi vanno eliminati durante questa migrazione.

Aggiungere la chiave pubblica: pannello di hosting o ~/.ssh/authorized_keys

Con un hosting gestito o condiviso, si apre la sezione accesso SSH o chiavi SSH. Si incolla la chiave pubblica, le si dà un nome riconoscibile e la si autorizza se il pannello lo richiede (cPanel prevede un passaggio «Authorize» separato).

Sul proprio server si aggiunge la chiave in coda al file authorized_keys dell'utente e si impostano permessi restrittivi:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat anna.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Se il login con password funziona ancora, ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host fa lo stesso dal computer della persona interessata. Conservare il commento alla fine di ogni riga di chiave (anna@example-company.eu): è ciò che permetterà di riconoscere la chiave fra due anni.

Provare il login con chiave, poi disattivare quello con password

Tenere aperta la sessione attuale o la scheda del pannello. In un secondo terminale si prova la nuova chiave:

ssh -i ~/.ssh/id_ed25519 user@host

Oppure ci si connette con il client SFTP usando il file della chiave. Solo quando funziona per tutte le persone che devono avere accesso si disattiva l'autenticazione con password. In un pannello di hosting è di solito un interruttore nella sezione SSH. Se in un hosting condiviso non lo si trova, si chiede all'host se per il proprio account si possono disattivare i login con password via SSH e FTP.

Sul proprio server si imposta in /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no

Controllare anche i file in /etc/ssh/sshd_config.d/: alcune immagini cloud includono un file aggiuntivo che imposta PasswordAuthentication yes. Prima di ricaricare, si convalida la configurazione e si verifica il valore effettivo:

sudo sshd -t
sudo sshd -T | grep -i passwordauthentication
sudo systemctl reload ssh

Sui sistemi basati su Red Hat il servizio si chiama sshd.

Da questo momento l'offboarding comprende un solo passaggio: il giorno in cui una persona se ne va, si elimina la riga della sua chiave.

FS_METHOD e credenziali FTP in wp-config.php

A volte WordPress mostra un modulo «Informazioni di connessione» quando si installa o si aggiorna un plugin. Succede perché PHP non può scrivere direttamente nei file, di solito per un problema di proprietà. Il nostro articolo sui permessi dei file di WordPress ne spiega la causa.

Una scorciatoia diffusa era inserire i dati FTP in wp-config.php:

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_HOST', 'ftp.example.de' );
define( 'FTP_USER', 'webuser' );
define( 'FTP_PASS', 'the-hosting-password' );

Gli aggiornamenti così funzionano, ma la password dell'hosting resta in chiaro in un file che PHP legge a ogni richiesta. Se wp-config.php trapela, per esempio da una copia di backup, da un server configurato male o da un plugin vulnerabile, con esso trapela l'accesso ai file. Per verificare la presenza di queste costanti:

grep -nE "FS_METHOD|FTP_(HOST|USER|PASS|SSL|PUBKEY|PRIKEY)" wp-config.php

Eseguire il controllo anche nella cartella superiore, perché in alcune configurazioni wp-config.php si trova un livello più su. Si rimuovono le costanti e si correggono le proprietà dei file in modo che WordPress possa scrivere direttamente. In tal caso funziona FS_METHOD impostato su 'direct', oppure lo si può omettere del tutto. 'ssh2' va usato solo dove l'estensione PHP ssh2 e una chiave dedicata sono configurate correttamente. Infine si elimina l'account FTP a cui si faceva riferimento o, almeno, se ne cambia la password. La documentazione di wp-config.php di WordPress descrive tutte queste costanti. La nostra checklist sul hardening di wp-config.php copre le altre impostazioni di quel file.

Il plugin gratuito Security Audit & Compliance di secaudit.eu analizza il sito alla ricerca di segreti e file esposti e di problemi di hardening, il che aiuta a individuare credenziali lasciate nel posto sbagliato. Non vede però l'elenco degli account FTP nel pannello di hosting, quindi l'inventario descritto sopra resta un lavoro manuale.

FAQ

FTPS è sufficiente se il mio host non offre SSH?

È accettabile come ripiego, perché il traffico è cifrato. Si imposta il client in modo che richieda TLS, si usa una password robusta e univoca per ciascuna persona e si eliminano comunque i vecchi account. Se l'host non offre alcun accesso SSH e non sa dire quando lo farà, conviene valutare il passaggio a un altro host.

Servono chiavi SSH per SFTP o basta una password?

SFTP con password è già molto meglio dell'FTP, perché la password viaggia cifrata. Le chiavi restano comunque preferibili: non si possono indovinare né sottrarre con una falsa pagina di login, perché la chiave privata non lascia mai il dispositivo. Usare una stessa chiave pubblica su più server non la espone come accade con una password riutilizzata, e ogni chiave può essere rimossa singolarmente.

Che cosa fare se qualcuno perde il portatile con una chiave?

Rimuovere la chiave pubblica di quella persona da ogni server e pannello lo stesso giorno. La passphrase fa guadagnare tempo, ma non è un motivo per aspettare. La persona genera poi una nuova coppia di chiavi sul nuovo dispositivo.

L'FTP in chiaro è un problema ai fini del GDPR?

Il GDPR, art. 32, par. 1, lett. a), cita la cifratura come esempio di misura di sicurezza adeguata. Accessi non cifrati a un server che contiene dati di clienti o dei moduli di contatto sono quindi difficili da giustificare. Il nostro articolo sull'articolo 32 del GDPR per WordPress spiega il resto della norma e l'approccio basato sul rischio.

Questo articolo è un'informazione generale e non costituisce consulenza legale.