evolix

wiki

21 KiB

Raw Permalink Blame History

Name: foo Quota Type: User Uploaded bytes: 182536110080.00 Downloaded bytes: 0.00 Transferred bytes: 0.00 Uploaded files: 0 Downloaded files: 0 Transferred files: 0

ftpquota --show-records --type=limit

Name: foo Quota Type: User Per Session: False Limit Type: Hard Uploaded bytes: 214748364800.00 Downloaded bytes: unlimited Transferred bytes: unlimited Uploaded files: unlimited Downloaded files: unlimited Transferred files: unlimited


Via FTP, vous pourrez voir les données de quota ainsi :

~~~{bash}
ftp> quote SITE QUOTA
200-Quota pour la session actuelle [courant / limite]:
200-Nom: foo
200-Type quota: Utilisateur
200-Par session : Faux
200-Type de limite : matérielle
200-  bytes:    182536110080.00/193273528320.00 envoyés
200-  bytes:    unlimited reçus
200-  bytes:    unlimited téléchargés
200-  files:    unlimited envoyés
200-  files:    unlimited reçus
200-  files:    unlimited téléchargés
200 Veuillez contacter ftpmaster@example.com si ces données sont inexactes

Enfin, on peut réinitialiser un compteur (tous les jours par exemple) :

# ftpquota --update-record --type=tally --name=foo --quota-type=user

Ou même effacer toutes les données de quota d'un utilisateur :

# ftpquota --delete-record --type=limit --name=foo --quota-type=user
# ftpquota --delete-record --type=tally --name=foo --quota-type=user

FTPS (FTP over SSL/TLS)

Note : A Evolix, nous ne proposons pour l'instant pas, sauf exception, les protocoles SFTP et FTPS.

On peut activer SSL/TLS en créant un fichier /etc/proftpd/tls.conf contenant les directives suivantes :

# vim /etc/proftpd/tls.conf
TLSEngine                               on
TLSLog                                  /var/log/proftpd/tls.log
TLSProtocol                             SSLv23
TLSRSACertificateFile                   /etc/proftpd/ssl/proftpd.crt
TLSCACertificateFile                    /etc/proftpd/ssl/proftpd.ca.crt
TLSRSACertificateKeyFile                /etc/proftpd/ssl/proftpd.key

Vérifiez que les certificats et la clé privé existent bien.

Il faut vérifier que le fichier est bien chargé par la configuration principale /etc/proftpd/proftpd.conf :

# vim /etc/proftpd/proftpd.conf
Include /etc/proftpd/tls.conf

Testez la configuration et rechargez la configuration :

# proftpd -t && systemctl reload proftpd.service

Testez la connexion :

# host=... # IP ou domaine
# lftp $host
lftp host:~> set ftp:ssl-force true
lftp host:~> login $ftp_user
Mot de passe :
lftp $ftp_user@host:~> ls

Si l'on peut lire le contenu du répertoire, alors la connexion est fonctionnelle.

SFTP (FTP over SSH)

A Evolix, sauf exception, nous préférons utiliser OpenSSH, qui propose lui aussi le protocole SFTP.

Généralement, on souhaite conserver un service FTP "classique" en parallèle de SFTP. On met donc sa configuration dans un VirtualHost, pour pouvoir écouter sur un deuxième port :

$ vim /etc/proftpd/conf.d/sftp.conf

LoadModule mod_sftp.c

<VirtualHost 0.0.0.0>
    <IfModule mod_sftp.c>

        SFTPEngine   on
        Port         2022
        DefaultRoot  ~

        SFTPLog      /var/log/proftpd/sftp.log

        SFTPAuthMethods password publickey
        # Uncomment ed25519 if ProFTPD >= 1.3.7 (Bullseye)
        # SFTPHostKey /etc/ssh/ssh_host_ed25519_key
        SFTPHostKey  /etc/ssh/ssh_host_ecdsa_key
        SFTPHostKey  /etc/ssh/ssh_host_rsa_key

        SFTPAuthorizedUserKeys file:/etc/proftpd/sftp.passwd.keys/%u
        AuthOrder    mod_auth_file.c
        AuthUserFile /etc/proftpd/vpasswd

        RequireValidShell off

    </IfModule>
</VirtualHost>

Note : Les clés publiques SSH des comptes SFTP dans le répertoire indiqué dans la directive SFTPAuthorizedUserKeys doivent être au format de la RFC 4716, qui n'est pas le format par défaut de SSH.

Si votre version de ProFTPd est antérieur à la 1.3.7 (Debian Bullseye) :

Les clés SSH indiquées dans ler directives SFTPHostKey doivent être au format de la RFC 4716, qui n'est pas le format par défaut de SSH.

Pour créer les clés privées compatibles côté serveur :

# ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N '' -m PEM
# ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -t ecdsa -N '' -m PEM

Si les fingerprints des clés sont stockées dans un système d'information, pensez à le mettre à jour (ssh-keyscan localhost est votre ami).

Ajouter un compte SFTP avec clé SSH

Suivre d'abord la section Ajouter un compte.

Puis, convertir la clé publique au format de la RFC 4716 et ajuster les droits :

$ ssh-keygen -e -f <PUBLIC_KEY> > /etc/proftpd/sftp.authorized_keys/<FTP_USER>
$ chmod 600 /etc/proftpd/sftp.authorized_keys/<FTP_USER>

Dans la configuration SFTP (/etc/proftpd/conf.d/sftp.conf), ajouter le nouvel utilisateur à la directive AllowUser .

Tester la configuration et la recharger :

# proftpd -t && systemctl reload proftpd.service

Tester la connexion via un mot de passe :

# lftp sftp://<USER>@<HOST>:<PORT>
Mot de passe :
lftp <USER>@<HOST>:~> ls

ou bien :

$ sftp -P <PORT> <USER>@<HOST>
<USER>@<HOST>'s password:
Connected to <HOST>
sftp> ls

Si l'on peut lire le contenu du répertoire, alors la connexion est fonctionnelle.

Troobleshooting clés SSH

Dans la configuration SFTP (/etc/proftpd/conf.d/sftp.conf), vérifier que la directive SFTPAuthMethods inclue publickey et que l'utilisateur est dans la liste des AllowUser.
Vérifier les permission du répertoire des clés publique SSH :

chmod 700 /etc/proftpd/sftp.authorized_keys/

Les fichiers de clés doivent être accessibles par l'utilisateur sous lequel ProFTPd tourne. Si les directives User et/ou Group sont utilisées, il faut ajuster les droits. Par exemple, avec User=proftpd et Group=proftpd, il faut (au minimum) que le dossier soit en root:proftpd 0750 et les fichiers soient en root:proftpd 0640.
Les clés publiques SSH des comptes SFTP dans le répertoire indiqué dans la directive SFTPAuthorizedUserKeys doivent être au format de la RFC 4716, qui n'est pas le format par défaut de SSH.
Si votre version de ProFTPd est antérieur à la 1.3.7, les clés SSH indiquées dans ler directives SFTPHostKey doivent être au format de la RFC 4716, qui n'est pas le format par défaut de SSH.

Logs

fichier xferlog

Troubleshooting

Problème d'envoi de fichier avec erreur `open for write: permission denied`

L'erreur est provoquée lorsque l'on veut écraser un fichier existant, il faut rajouter la directive AllowOverwrite on dans le la configuration de ProFTPD ou du VirtualHost concerné.

On la positionne dans une balise <Directory> comme ceci :

<Directory /home/*>
    AllowOverwrite      on
</Directory>

Problèmes d'accès

En cas d'erreurs d'accès, bien vérifier que les ports 20 et 21 sont ouverts, ainsi que les ports passifs :

iptables -A INPUT -p tcp --dport 60000:61000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

En cas d'erreurs de permission, il vérifier que l’UID et le GID sont bien mis explicitement (en chiffres) comme propriétaires des répertoires et fichiers auxquels l'utilisateur FTP est censée avoir accès. En effet, ProFTPd n’est pas capable de lire les noms des utilisateurs Unix dans /etc/passwd.

Client sent GLOBAL_REQUEST, denying

D'après la documentation de ProFTPd, ce message dans les logs n'est pas une erreur mais fait partie des mécanismes normaux de keep-alive de SSH :

2023-06-26 11:31:50,812 mod_sftp/0.9.9[15505]: client sent GLOBAL_REQUEST for 'keepalive@jcraft.com', denying

On peut le vérifier dans la fonction handle_global_request_msg() du code-source, en cas de GLOBAL_REQUEST, ce message est toujours écrit dans les logs.

21 KiB Raw Permalink Blame History Unescape Escape