ProFTPd

Dopo secoli torno a parlare di tecnologia e lo faccio nel modo più classico del mondo: sono inciampato in un argomento apparentemente banale, in realtà spinoso. Uscitone vittorioso, ne condivido il percorso, per la gioia di grandi e piccini.

Task: installare un server FTP su una macchina linux e configurarlo per degli accessi da utenti specifici.
Livello di banalità apparente: 10/10
Sbatti reale: 1000

La prima cosa è scegliere quale server installare. La macchina ha su Debian e la scelta si gioca principalmente fra ProFTPd, PureFTPd e vsftpd. Qui un breve confronto fra i tre concorrenti.
Per ragioni che non sto a sviscerare scelgo ProFTPd.

NOTA BENE: questa non è una guida alla configurazione sicura e ottimizzata del serer proFTPd e non intende esserlo, ma è solo una guida veloce a come risolvere dei problemi comuni senza perdere ore su internet e vagare per mille pagine di manuale, dando invece una visione organica e funzionale in pochi minuti.

L'installazione è banale come un semplice

apt-get install proftpd-basic

Un attimo e siamo online...e invece? E invece scegliendo per un server gestito da xined invece che standalone ci si butta in un piccolo delirio che non vale la pena di affrontare: le risorse occupate sono oggettivamente così poche che vale la pena tenerlo acceso e risparmiarsi lo sbatti.
Quindi, nella configurazione ( /etc/proftpd/proftpd.conf ) bisogna assicurarsi di avere la riga:

ServerType                      standalone

E con questo, magia, parte.
Primo accesso con un utente di sistema e tutto funziona. Ma come si arginano gli utenti a non andare in giro a curiosare per il mondo?
La cara vecchia impostazione dei permessi potrebbe pure essere una strada, ma non è praticabile, perchè significa precludere agli utenti locali di girovagare per il sistema. Quindi?
Quindi la risposta è in questa riga nel file di conf:

DefaultRoot ~

Ossia gli utenti si trovano ad avere la loro home ( ~, appunto, per chi non ha dimestichezza) come root, durante il loro accesso ftp. Da lì non si esce. Ci sono degli effetti collaterali, in questo, che sono ben spiegati in questa pagina sul chroot.

Per riavviare il server basta il solito:

/etc/init.d/proftpd restart

Fatto?
No, a meno che non vogliate creare un utente di sistema per ogni utente ftp, cosa che a volte va bene e a volte no.
Qui parte uno sbatti facile, ma lungo e articolato, se non ci avete mai avuto a che fare.

Step 1: abilitare l'autenticazione su un file alternativo

Nel file di conf deve essere aggiunta una riga come questa:

AuthOrder                       mod_auth_unix.c mod_auth_file.c

dove mod_auth_file.c indica che proFTPd può leggere i dati di autenticazione dell'utente in un file ad hoc separato da quello delle password di unix/linux. Qui si può leggere un approfondimento, che parla anche della questione del chroot discussa prima.
L'ordine conta e quindi prima il server usa mod_auth_unix.c (verifica fra gli utenti di sitema), poi in un file esterno.
Ma quale file?

Step 2: indicare il file alternativo di autenticazione

Semplice, si fa con questa riga:

AuthUserFile /etc/proftpd/vusers.conf

si indica dov'è il file in questione. Il path è arbitrario, come il nome file. Meglio scegliere un percorso fuori dal path raggiungibile/visibilie/modificabile dagli utenti. Nel mio caso l'ho messo nella stessa cartella del file principale di configurazione.
Il file deve essere esistente e leggibile, ma può anche essere vuoto.

Step 3: popolare il file per gli utenti virtuali

Un file di utenti vuoto serve a poco. Il modo più facile per popolarlo è usare il comando ftpasswd.
Per usarlo basta scrivere nella shall:

ftpasswd --passwd --file=/etc/proftpd/vusers.conf --name=myuser --uid=15000 --home=/path/to/home --shell=/bin/sh

Il comando chiede la password da assegnare al'utente e ne mette una hash nel file selezionato, alla riga dell'utente. Se l'utente esiste già propone di modificare la password, altrimenti appende una nuova riga per il nuovo utente al file.

Dove --file indica il path al file indicato nel file di cofigurazione di proFTPd, e --uid è un qualunque uid (user ID, per i neofitissimi), anche inventato. Si può specificare anche un group id che, se omesso, è di default uguale all'uid.

La home per l'utente non viene creata, quindi deve essere un path esistente (non necessariamente subito, ma al primo accesso). La shell ha usi speciali che non interessano adesso, ma deve essere una shell esistente, quindi /bin/sh è la scelta di comodo.

Se volete che l'utente entri con lo stesso utente con cui gira apache, quindi possa leggere e scrivere in una cartella da cui legge e scrive una web-app, basta indicare lo uid di quell'utente. Per esempio, su debian/ubuntu l'utente è www-data, nel fail /etc/passwd c'è una riga relativa all'utente www-data ad cui si può prendere lo uid assegnatogli.
Stessa cosa per qualunque altro utente, se volete evitare la configurazione di dettaglio dei permessi.

ATTENZIONE: non mettete un utente virtuale con la home in una cartella in cui può fare danni. Per girare intorno al problema create nella webapp un link alla home dell'utente. In questo modo la webapp accede con percorsi relativi alla cartella ftp, ma non viceversa.


The END!
A questo punto è tutto configurato, e basta un semplice riavvio del server per vedere tutto funzionare. Volendo si può riavviare già alla fine dello step 2, dal momento che il contenuto del file degli utenti è letto dinamicamente al login.

Note di sistema
Mentre tutto va beatamente liscio usando debian/ubuntu, centOS riserva, tanto per cambiare, le sue piccole e fastidiose sorprese.
Prima fra tutte, il pacchetto proftpd NON è disponibile di default con yum.
Per usarlo bisogna seguire questi semplici step (presi in prestito dai tutorial di Digital Ocean, visto che decine di alternative simili che si trovano online non funzionano e si rischia di perdere ore alla ricerca del repository giusto...e non imbarcatevi nel download degli rpm, perchè le dipendenze sono più forti di quelle di un tossico allo stadio terminale), che sono però duri da trovare online:


rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

e magicamente ci appare il pacchetto...ora si può pacificamente fare:

yum install proftpd

Inutile dire che la struttura dei file di configurazione cambia, ma il senso no. Banalmente proftpd.conf non è più in /etc/proftpd ma direttamente in /etc. Fossero questi i problemi....


Enjoy ;)