Ycharbi : /* SFTP */ Correction d'une faute de français

2024-09-01T20:51:37Z

SFTP : Correction d'une faute de français

← Version précédente		Version du 1 septembre 2024 à 22:51
Ligne 10 :		Ligne 10 :

	==SFTP==		==SFTP==
	De nos jours, l'utilisation des protocoles ''FTP'' et sont pendant chiffré, ''FTPS'', est dépréciée. Les raisons principales de cette tendance, malgré les qualités indéniables de ces derniers ~~est~~ principalement dû à l'explosion des ''NAT/PAT'' sur les réseaux ''WAN'' ainsi que la systématisation des règles de pare-feux. ''FTP'' est en effet un vieux protocole imaginé à une époque où il était normal (allez savoir pourquoi) d'utiliser une multitude de ports pour réaliser une action simple. Aussi, le port 20/''TCP'' était utilisé pour les données alors que le 21/''TCP'' servait pour transmettre les commandes. La version chiffrée quant à elle utilisait carrément des plages de ports au dessus de 1024 en plus de ceux mentionnés, rendant toute tentative de filtrage fin veine et occasionnait des problèmes de fiabilité avec certaines passerelles ''NAT'' (que je n'ai pour ma part jamais rencontré).		De nos jours, l'utilisation des protocoles ''FTP'' et sont pendant chiffré, ''FTPS'', est dépréciée. Les raisons principales de cette tendance, malgré les qualités indéniables de ces derniers sont principalement dû à l'explosion des ''NAT/PAT'' sur les réseaux ''WAN'' ainsi que la systématisation des règles de pare-feux. ''FTP'' est en effet un vieux protocole imaginé à une époque où il était normal (allez savoir pourquoi) d'utiliser une multitude de ports pour réaliser une action simple. Aussi, le port 20/''TCP'' était utilisé pour les données alors que le 21/''TCP'' servait pour transmettre les commandes. La version chiffrée quant à elle utilisait carrément des plages de ports au dessus de 1024 en plus de ceux mentionnés, rendant toute tentative de filtrage fin veine et occasionnait des problèmes de fiabilité avec certaines passerelles ''NAT'' (que je n'ai pour ma part jamais rencontré).

	Cependant, la vacance occasionnée par la dépréciation de ces protocoles n'a jamais été réellement comblée. [[Apache2#Partage_WebDAV\|WebDAV]] n'est pas très fiable dans ces implémentations (surtout sous [[Windows_net_use#Usages_concrets\|Windows]]) et est plus que casse pied à configurer côté serveur (y'a toujours un truc qui va pas) ; ''HTTP'' seul ne permet pas le transfert de répertoires, [[Samba]] et [[Nfs\|NFS]] ne sont pas fait pour du ''WAN'' en plus de proposer une sécurité (surtout pour ce dernier) très discutable, ''ISCSI'' ne fonctionne qu'en mode bloc ; [[Sftp-server\|SFTP]] embarqué dans un serveur ''SSH'' utilise traditionnellement des utilisateurs ''POSIX'', ce qui oblige à porter une attention toute particulière au durcissement de la configuration en plus de permettre des répercutions catastrophiques en cas de faille (un utilisateur destiné au transfert de fichiers peut, en fin de compte, se connecter au serveur...) ; etc... Aucun remplaçant potentiel n'a donc su prendre la relève avec la légèreté et les fonctionnalités du protocole de transfert de fichiers (''File Transfer Protocol'') traditionnel :		Cependant, la vacance occasionnée par la dépréciation de ces protocoles n'a jamais été réellement comblée. [[Apache2#Partage_WebDAV\|WebDAV]] n'est pas très fiable dans ces implémentations (surtout sous [[Windows_net_use#Usages_concrets\|Windows]]) et est plus que casse pied à configurer côté serveur (y'a toujours un truc qui va pas) ; ''HTTP'' seul ne permet pas le transfert de répertoires, [[Samba]] et [[Nfs\|NFS]] ne sont pas fait pour du ''WAN'' en plus de proposer une sécurité (surtout pour ce dernier) très discutable, ''ISCSI'' ne fonctionne qu'en mode bloc ; [[Sftp-server\|SFTP]] embarqué dans un serveur ''SSH'' utilise traditionnellement des utilisateurs ''POSIX'', ce qui oblige à porter une attention toute particulière au durcissement de la configuration en plus de permettre des répercutions catastrophiques en cas de faille (un utilisateur destiné au transfert de fichiers peut, en fin de compte, se connecter au serveur...) ; etc... Aucun remplaçant potentiel n'a donc su prendre la relève avec la légèreté et les fonctionnalités du protocole de transfert de fichiers (''File Transfer Protocol'') traditionnel :

Ycharbi : Page créée avec « Category:Service_partage [http://proftpd.org/ ProFTPd] est un logiciel permettant de monter un serveur de fichiers basé sur les protocoles ''FTP'' ; ''FTPS'' et SFTP. Il a la particularité d'utiliser des fichiers de configuration proches de ceux d'Apache2. =Installation= Référence dans son domaine, il est probablement disponible dans les dépôts de la distribution ''Linux'' que vous utilisez. Pour ''Debian 12'', la commande suivante... »

2024-09-01T20:47:06Z

Page créée avec « Category:Service_partage [http://proftpd.org/ ProFTPd] est un logiciel permettant de monter un serveur de fichiers basé sur les protocoles ''FTP'' ; ''FTPS'' et SFTP. Il a la particularité d'utiliser des fichiers de configuration proches de ceux d'Apache2. =Installation= Référence dans son domaine, il est probablement disponible dans les dépôts de la distribution ''Linux'' que vous utilisez. Pour ''Debian 12'', la commande suivante... »

Nouvelle page

[[Category:Service_partage]]

[http://proftpd.org/ ProFTPd] est un logiciel permettant de monter un serveur de fichiers basé sur les protocoles ''FTP'' ; ''FTPS'' et [[Sftp-server|SFTP]]. Il a la particularité d'utiliser des fichiers de configuration proches de ceux d'[[Apache2]].

=Installation=
Référence dans son domaine, il est probablement disponible dans les dépôts de la distribution ''Linux'' que vous utilisez. Pour ''Debian 12'', la commande suivante permet d'installer le paquet
apt install --no-install-recommends proftpd proftpd-mod-crypto

''ProFTPd'' supporte un grand nombre de modules. Le paquet <code>proftpd-mod-crypto</code> permet d'utiliser ''FTP'' sur ''TLS'', aussi appelé ''FTPS'' ainsi que ''SFTP'', le protocole de transfert de fichiers sur [[Openssh|SSH]].

==SFTP==
De nos jours, l'utilisation des protocoles ''FTP'' et sont pendant chiffré, ''FTPS'', est dépréciée. Les raisons principales de cette tendance, malgré les qualités indéniables de ces derniers est principalement dû à l'explosion des ''NAT/PAT'' sur les réseaux ''WAN'' ainsi que la systématisation des règles de pare-feux. ''FTP'' est en effet un vieux protocole imaginé à une époque où il était normal (allez savoir pourquoi) d'utiliser une multitude de ports pour réaliser une action simple. Aussi, le port 20/''TCP'' était utilisé pour les données alors que le 21/''TCP'' servait pour transmettre les commandes. La version chiffrée quant à elle utilisait carrément des plages de ports au dessus de 1024 en plus de ceux mentionnés, rendant toute tentative de filtrage fin veine et occasionnait des problèmes de fiabilité avec certaines passerelles ''NAT'' (que je n'ai pour ma part jamais rencontré).

Cependant, la vacance occasionnée par la dépréciation de ces protocoles n'a jamais été réellement comblée. [[Apache2#Partage_WebDAV|WebDAV]] n'est pas très fiable dans ces implémentations (surtout sous [[Windows_net_use#Usages_concrets|Windows]]) et est plus que casse pied à configurer côté serveur (y'a toujours un truc qui va pas) ; ''HTTP'' seul ne permet pas le transfert de répertoires, [[Samba]] et [[Nfs|NFS]] ne sont pas fait pour du ''WAN'' en plus de proposer une sécurité (surtout pour ce dernier) très discutable, ''ISCSI'' ne fonctionne qu'en mode bloc ; [[Sftp-server|SFTP]] embarqué dans un serveur ''SSH'' utilise traditionnellement des utilisateurs ''POSIX'', ce qui oblige à porter une attention toute particulière au durcissement de la configuration en plus de permettre des répercutions catastrophiques en cas de faille (un utilisateur destiné au transfert de fichiers peut, en fin de compte, se connecter au serveur...) ; etc... Aucun remplaçant potentiel n'a donc su prendre la relève avec la légèreté et les fonctionnalités du protocole de transfert de fichiers (''File Transfer Protocol'') traditionnel :
* installation et utilisation simple
* utilisateurs virtuels avec base de données de multiple types allant du fichier plain à la base [[MariaDB - Gestion utilisateurs|SQL]] en passant par l'annuaire [[Ldap|LDAP]]
* emprisonnement des comptes utilisateurs dans un répertoire (''chroot'')
* pas de ''shell''
* gestion des droits
* reprise de téléchargements partiels
* performances maximales
* support très large

L'implémentation de ''SFTP'' proposée par ''ProFTPd'' s'avère alors particulièrement intéressante car elle est décorrélée de tout serveur ''SSH'' et permet l'utilisation de comptes virtuels emprisonnés sans utilisation de ''shell'', réduisant ainsi drastiquement la surface d'attaque. De plus, ce logiciel est reconnu comme apportant un soin prononcé à la sécurité et est éprouvé depuis plusieurs décennies. Il permettra donc de proposer un service quasiment similaire tout en apportant la confidentialité exigée par l'époque...

===Configuration du service===
En mode ''SFTP'' uniquement
mv /etc/proftpd/proftpd.conf /etc/proftpdproftpd.conf.ori

<syntaxhighlight lang="bash">
cat << '_EOF_' > /etc/proftpd/proftpd.conf
# Chargement du module SFTP
LoadModule mod_sftp.c

# Désactiver le service FTPS
<IfModule mod_tls.c>
TLSEngine off
</IfModule>

# Activer SFTP
<IfModule mod_sftp.c>
SFTPEngine on
Port 2222
# Pièger l'utilisateur (chroot) dans son répertoire personnel
DefaultRoot ~
# Journalisation
SFTPLog /var/log/proftpd/sftp.log
SyslogLevel info
TransferLog /var/log/proftpd/xferlog
SystemLog /var/log/proftpd/proftpd.log
# UseLastlog on

SFTPHostKey /etc/proftpd/ssh_host_ed25519_key

# Méthode d'authentification
SFTPAuthMethods publickey
SFTPAuthorizedUserKeys file:/etc/proftpd/authorized_keys/%u
RequireValidShell off
</IfModule>

# Utiliser les utilisateurs virtuels
<IfModule mod_auth.c>
AuthOrder mod_auth_file.c
</IfModule>

# Base des utilisateurs virtuels
<IfModule mod_auth_file.c>
AuthUserFile /etc/proftpd/ftpd.passwd
AuthGroupFile /etc/proftpd/ftpd.group
</IfModule>

# Limiter l'accès aux utilisateurs virtuels
<Limit LOGIN>
AllowUser toto
DenyAll
</Limit>
_EOF_
</syntaxhighlight>

{{astuce|La configuration proposée impose l'usage de clés ''SSH'' pour la connexion des clients. Pour permettre l'utilisation des mots de passes en cas d'absence de clé, le mot <code>password</code> peut être ajouté à la suite après un espace dans le paramètre correspondant de la façon suivante : <code>SFTPAuthMethods publickey password</code>.}}

L'outil '''exige''' que le nom d'hôte redirige obligatoirement sur son adresse ''IP'' (il doit probablement utiliser cette information pour la création du socket ''TCP''). Définissez cette donnée en l'adaptant à votre configuration :
echo -e "10.0.0.100\t${HOSTNAME}" >> /etc/hosts

===Éléments secrets===
Génération d'une clé ''SSH'' serveur
ssh-keygen -t ed25519 -f /etc/proftpd/ssh_host_ed25519_key -N ""
chmod 600 /etc/proftpd/ssh_host_ed25519_key

Utilisation des clés ''SSH'' pour les clients
mkdir /etc/proftpd/authorized_keys

''Proftpd'' utilise volontairement un format de clé ''SSH'' différent d'[[Openssh|OpenSSH]] pour éviter les conflits avec ce dernier. Il a ainsi choisit la forme décrite dans la [https://www.rfc-editor.org/rfc/rfc4716 RFC 4716]. Il est possible de convertir une clé existante sans altération de l'originale (par retour sur ''stdout'') via la commande suivante sur le client
ssh-keygen -e -f ~/.ssh/id_ed25519.pub

Le résultat est à mettre dans le fichier de clés portant le nom de votre utilisateur ([http://www.proftpd.org/docs/contrib/mod_sftp.html#SFTPAuthorizedUserKeys directive] <code>SFTPAuthorizedUserKeys file:/etc/proftpd/authorized_keys/%u</code>).

Exemple avec l'utilisateur ''toto''

<syntaxhighlight lang="bash">
cat << '_EOF_' >> /etc/proftpd/authorized_keys/toto
---- BEGIN SSH2 PUBLIC KEY ----
VOTRE
CLÉ PUBLIQUE
AU FORMAT
RFC 4716
---- END SSH2 PUBLIC KEY ----
_EOF_
</syntaxhighlight>

Il est bien entendu possible de chaîner plusieurs clés dans ce même fichier. Il y aura donc autant de sections ''BEGIN/END'' que de clés.

chmod 600 /etc/proftpd/authorized_keys/toto

===Utilisateurs virtuels===
Création du répertoire personnel de l'utilisateur virtuel
mkdir -p /var/lib/proftpd/toto
chown 2000:2000 /var/lib/proftpd/toto

Création dudit utilisateur
ftpasswd --passwd --file=/etc/proftpd/ftpd.passwd --uid=2000 --gid 2000 --home=/var/lib/proftpd/toto --shell=/bin/false --sha256 --name=toto
ftpasswd --group --file=/etc/proftpd/ftpd.group --gid=2000 --member=toto --name=Moi

{{astuce|Il est possible de remplacer le mot de passe haché par un <code>!</code> ou tout autre caractère ne correspondant pas à un mot de passe haché dans le fichier <code>passwd</code> afin de désactiver le mot de passe. L'option <code>-l</code> ou <code>--lock</code> peut également être passée à la [http://www.proftpd.org/docs/contrib/ftpasswd.html commande] de création de l'utilisateur (concatène ce caractère au mot haché). Seule les connexions par clé ''SSH'' seront alors autorisées.}}

===Test et application===
Il est possible de tester la configuration avec la commande suivante
proftpd -t -d 10

Le paramètre <code>-d</code> permet d'augmenter le niveau de verbosité du journal sur la sortie standard (de 0 à 10). Il est également possible d'augmenter le niveau de journalisation en conduite en passant la valeur <code>debug</code> à la directive <code>SyslogLevel</code>.

Redémarrer le service pour prendre en compte les modifications (inutile pour la création ou le changement de mot de passe d'un utilisateur)
systemctl restart proftpd.service

Vous pouvez désormais utiliser un client ''SFTP'' pour vérifier le bon fonctionnement.

Exemple avec celui d{{'}}''OpenSSH'' :
sftp -oPort=2222 toto@10.0.0.100
ou
sftp -P 2222 toto@10.0.0.100

===Sources de la section===
* http://www.proftpd.org/docs/directives/
* https://linux.die.net/man/8/proftpd
* https://fr.linux-console.net/?p=5239
* https://blog.victor-hery.com/2019/03/installer-sftp-proftpd.html

Proftpd - Historique des versions

Ycharbi : /* SFTP */ Correction d'une faute de français

Ycharbi : /* SFTP */ Correction d'une faute de français