Come installare SFTPGo su Ubuntu 24.04 e 22.04 LTS

Perché SFTPGo e quando usarlo

SFTPGo è una scelta pratica quando serve offrire SFTP, FTP/S, WebDAV o accesso HTTP/S a file e cartelle con un unico motore di autenticazione e una gestione più ordinata rispetto a configurazioni sparse tra OpenSSH, web server e script custom. Su Ubuntu 24.04 e 22.04 LTS l’installazione è lineare, ma il punto non è “far partire il servizio”: il punto è farlo bene, con permessi chiari, storage separato, TLS corretto e un piano di rollback se qualcosa va storto.

Qui parto da un’installazione server-side su macchina fresca o quasi, con accesso root o sudo, e con l’idea che il servizio esponga almeno SFTP. Se poi vuoi abilitare Web UI, WebDAV o storage backend esterni, la base resta la stessa: prima si mette in piedi il demone, poi si irrigidisce l’accesso, infine si espongono i servizi necessari.

Scelta del modello: utente locale, database o backend esterno

Prima di installare, conviene decidere come SFTPGo dovrà gestire gli account. Per un ambiente piccolo o un primo rollout, la strada più semplice è usare utenti locali gestiti dal pannello o dalla CLI del prodotto. Per ambienti con più operatori o automazione, ha più senso appoggiarsi a un database o a un provider esterno. La differenza pratica è semplice: se cambi gestione utenti dopo, la migrazione è possibile ma non è più un lavoro “di installazione”, diventa un cambio di architettura.

Per una macchina singola, con storage locale e pochi account, il binomio più pulito è: servizio systemd, directory dati dedicata, porta SFTP non esposta oltre il necessario e accesso amministrativo limitato. È la configurazione che riduce gli errori iniziali e ti lascia margine per crescere.

Installazione su Ubuntu 24.04 e 22.04 LTS

Il metodo più comodo è il repository ufficiale o il pacchetto distribuito dal progetto. La procedura può cambiare nel tempo, quindi il primo controllo è sempre verificare la fonte di installazione disponibile per la tua versione di Ubuntu. Se il repository ufficiale è presente, il flusso tipico è: aggiunta chiave, repository, aggiornamento index, installazione del pacchetto.

Se la documentazione del progetto indica un repository APT, la sequenza operativa è questa. Usa sempre il canale ufficiale del progetto e non copiare chiavi o URL da fonti terze.

1. Aggiorna la macchina e prepara i prerequisiti.

sudo apt update
sudo apt -y upgrade
sudo apt -y install curl ca-certificates gnupg

Se il sistema è appena installato, questo passaggio serve anche a evitare di diagnosticare come “problema di SFTPGo” un bug già risolto nella base OS.

2. Aggiungi il repository ufficiale del progetto, se previsto dalla tua release.

Qui non invento URL o fingerprint: vanno presi dalla pagina ufficiale di rilascio del progetto per Ubuntu 22.04 e 24.04. Il controllo da fare è sempre lo stesso: il pacchetto deve arrivare da una sorgente firmata e riconoscibile in `apt policy`.

apt-cache policy sftpgo

Se vedi una priorità coerente e il repository atteso, sei a posto. Se il pacchetto non compare, la chiusura del gap è banale: recuperare il metodo di installazione aggiornato dal sito ufficiale del progetto e ripetere l’aggiunta repository.

3. Installa il pacchetto.

sudo apt update
sudo apt -y install sftpgo

Dopo l’installazione, verifica che il servizio sia presente e abilitato all’avvio.

systemctl status sftpgo --no-pager
systemctl is-enabled sftpgo

Atteso: stato active (running) o comunque un servizio installato ma ancora da configurare, e abilitazione coerente con la tua policy di startup.

Prima verifica: porte, processo e file di configurazione

Prima di toccare l’interfaccia web o aprire firewall, controlla che il demone stia ascoltando dove ti aspetti. È il modo più rapido per capire se il problema è nel servizio o nell’esposizione di rete.

ss -ltnp | grep -i sftpgo
journalctl -u sftpgo -n 50 --no-pager

Se non vedi porte in ascolto, il log di systemd è il primo posto da leggere. In caso di errore di parsing della configurazione, il messaggio è di solito esplicito e ti porta al file corretto. In molte installazioni il file principale si trova in un percorso del tipo /etc/sftpgo/, ma il path reale va verificato con il pacchetto installato, non dato per scontato.

Configurazione iniziale: binding, storage e UI

La configurazione iniziale deve risolvere tre domande: su quale indirizzo ascolta SFTPGo, dove salva i dati e se la web interface è esposta solo localmente o anche in rete. La scelta prudente è tenere la UI su localhost o su una rete amministrativa, non su Internet aperto, almeno finché non hai TLS, autenticazione forte e una policy di accesso chiara.

Se il pacchetto installato fornisce un file di configurazione YAML o JSON, fai un backup prima di modificarlo. Questo è il rollback minimo e va considerato parte della procedura, non un dettaglio opzionale.

sudo cp /etc/sftpgo/sftpgo.json /etc/sftpgo/sftpgo.json.bak

Il path qui è un esempio: sostituiscilo con il file reale presente nel tuo sistema. Se non sai dov’è, cerca i file installati dal pacchetto.

dpkg -L sftpgo | grep -E 'config|yaml|json|service'

Per un primo avvio, conviene mantenere una configurazione semplice: una porta SFTP standard, una porta web amministrativa separata e storage locale su filesystem con permessi stretti. Se usi una directory dedicata come /srv/sftpgo, crea prima il path e assegna il proprietario corretto.

sudo install -d -o sftpgo -g sftpgo -m 0750 /srv/sftpgo

Se il pacchetto usa un utente di sistema diverso, verifica il nome con systemctl cat sftpgo o con i campi User= e Group= del servizio. Non assumere mai che il nome dell’utente coincida con il nome del demone.

Avvio del servizio e controllo del bootstrap

Dopo aver sistemato la configurazione minima, riavvia il servizio e controlla il bootstrap in tempo reale. Qui il segnale utile è doppio: processo attivo e assenza di errori ripetuti nel journal.

sudo systemctl restart sftpgo
sudo journalctl -u sftpgo -f

Se il servizio si ferma subito, i casi più comuni sono: porta già in uso, file di configurazione non valido, permessi errati sulla directory dati o certificati mancanti se hai già abilitato TLS. La falsificazione rapida passa dai log: il primo errore utile appare quasi sempre nei primi 20-30 secondi.

Creazione del primo utente e test SFTP

Una volta che il demone è vivo, il test vero è autenticarsi con un client SFTP. Se il sistema di gestione utenti è locale o integrato, crea un account di prova con home directory esplicita e permessi limitati. L’obiettivo non è “fare login”, ma verificare che il mapping tra utente, home e filesystem sia coerente.

La CLI di amministrazione, se presente nel pacchetto, è spesso il modo più rapido per creare un utente senza passare dalla UI. Il comando esatto può variare in base alla versione, quindi il controllo corretto è consultare l’hint locale del binario installato.

sftpgo --help
sftpgo admin --help

Il test lato client è semplice:

sftp -P 2022 nomeutente@server.example.com

Sostituisci la porta con quella realmente configurata. Se il login funziona ma la directory risulta vuota o non scrivibile, il problema è quasi sempre nei permessi del filesystem o nella home associata all’utente. In quel caso il journal del servizio e i log del client ti dicono se stai vedendo un rifiuto di autenticazione o un errore di autorizzazione post-login.

TLS per la web interface e per i servizi esposti

Se esponi la web interface oltre localhost, TLS non è una decorazione: è il requisito minimo. Hai due strade sensate. La prima è terminare TLS direttamente in SFTPGo se vuoi tenere tutto in un solo processo. La seconda è mettere un reverse proxy davanti, utile se hai già standardizzato Nginx o Apache per altri servizi.

La scelta dipende dall’operatività. Se il server ha solo questo servizio e vuoi meno parti mobili, il TLS nativo è più semplice. Se invece hai già un proxy con certificati automatizzati, centralizzare lì riduce duplicazione di configurazione.

Qualunque sia il modello, controlla sempre tre cose: certificato valido, catena completa e redirect coerente tra HTTP e HTTPS. Il test minimo è un curl -I verso la UI e la verifica del certificato lato client.

curl -Ik https://server.example.com
openssl s_client -connect server.example.com:443 -servername server.example.com

Atteso: risposta HTTP coerente, certificato emesso per il nome giusto e assenza di errori di chain. Se vedi warning sul nome host o sulla CA, il fix non è “forzare il client”: è correggere il certificato o il proxy.

Hardening minimo che vale davvero la pena fare

Qui la regola è semplice: meno esposizione, meno privilegi, meno ambiguità. SFTPGo non va trattato come un’applicazione monolitica da lasciare aperta in rete senza contromisure. Il set minimo di hardening è piccolo ma efficace.

1. Lascia la web admin accessibile solo da IP fidati o da una VPN.
2. Usa password forti o, meglio, autenticazione chiave dove applicabile.
3. Disabilita i servizi che non servono: se non usi FTP o WebDAV, non abilitarli “per comodità”.
4. Conserva i dati su filesystem dedicato con permessi stretti e senza montaggi generici in scrittura.
5. Controlla i log e imposta una retention minima per non perdere evidenza sugli errori di login o sui tentativi anomali.

Se il server è esposto a Internet, aggiungi anche un controllo lato firewall. Non è una misura sostitutiva, ma riduce il rumore e limita la superficie d’attacco. Su Ubuntu, il controllo operativo passa spesso da UFW o dalla policy del cloud provider.

sudo ufw status verbose
sudo ss -ltnp

Il criterio di successo è chiaro: solo le porte necessarie devono essere in ascolto e solo gli indirizzi necessari devono raggiungerle.

Integrazione con systemd: avvio, restart e logging

Su Ubuntu, il servizio deve stare sotto systemd in modo pulito. Questo ti dà avvio automatico, restart controllato e log centralizzati. Se non trovi l’unit file, o è stato installato in modo non standard oppure il pacchetto non è quello giusto.

systemctl cat sftpgo
systemctl enable --now sftpgo

Se devi cambiare parametri del servizio, preferisci un override rispetto alla modifica diretta dell’unit file. È la strada più pulita per gli aggiornamenti futuri.

sudo systemctl edit sftpgo

In un override puoi inserire variabili d’ambiente, limiti di risorse o path aggiuntivi senza toccare i file del pacchetto. Il rollback è immediato: rimuovi l’override e ricarichi systemd.

Problemi tipici dopo l’installazione e come leggerli

Le anomalie più frequenti non sono misteriose: servizio avviato ma non raggiungibile, login rifiutato, accesso riuscito ma directory sbagliata, TLS rotto o porta occupata. Il trucco è non confondere il layer di errore.

1. Porta in uso: verifica con ss -ltnp e libera il binding o cambia porta.
2. Permessi errati: controlla owner e mode della directory dati con namei -l /srv/sftpgo.
3. Configurazione non valida: leggi il journal e valida il file prima del restart.
4. Certificato non valido: verifica CN/SAN e catena con openssl s_client.
5. Login fallito: controlla se l’account esiste davvero e se la home è stata mappata nel modo previsto.

Quando il problema è ambiguo, il primo strumento è sempre il log del servizio, non il riavvio ripetuto. Riavviare a vuoto consuma solo tempo e sporca la timeline degli eventi.

Rollback pulito e manutenzione futura

Ogni modifica fatta in questa fase deve avere un rollback semplice. Per la configurazione, il backup del file originale è sufficiente. Per il servizio, basta disabilitare l’override o ripristinare il file salvato. Per i dati, se hai creato una directory dedicata, non mischiare i file di test con quelli reali: separare gli ambienti è il modo più economico per evitare ripristini sporchi.

sudo cp /etc/sftpgo/sftpgo.json.bak /etc/sftpgo/sftpgo.json
sudo systemctl restart sftpgo

Se hai usato un reverse proxy, conserva anche la configurazione del virtual host o del server block in un file versionato. In caso di regressione, il rollback del proxy è spesso più veloce di quello dell’applicazione.

Sequenza consigliata in pratica

Se vuoi fare l’installazione senza girare intorno al problema, la sequenza sensata è questa: aggiorna il sistema, installa SFTPGo dal canale ufficiale, verifica il servizio, prepara la directory dati, configura binding e UI, avvia il demone, crea un utente di test, prova il login, poi aggiungi TLS e hardening. Cambiare ordine aumenta la probabilità di inseguire errori che in realtà sono solo effetti collaterali.

Su Ubuntu 22.04 e 24.04 il punto non è la compatibilità in sé, ma la disciplina operativa: repository affidabile, file di configurazione tracciato, log letti prima dei restart, porte limitate e rollback pronto. Con questa impostazione SFTPGo diventa un servizio gestibile, non un altro componente fragile da ricordarsi solo quando smette di rispondere.