Installation de SFTPGo sur eole3

Installation de SFTPGo sur eole3

Objectif

Mettre en place un serveur SFTP moderne permettant :

• la gestion fine des accès ;
• la séparation logique des données via des virtual folders ;
• la gestion des quotas indépendamment de ZFS ;
• une alternative à OpenSSH SFTP utilisé en mode secours.

---

Pré-requis

• serveur Ubuntu 24 (noble) fonctionnel ;
• accès root ;
• datasets clients déjà montés sous /var/data/ ;
• groupe pleade existant ;
• service SSH déjà configuré.

---

Installation du dépôt SFTPGo

Installation des dépendances :

apt update
apt install -y software-properties-common

Ajout du dépôt officiel via PPA :

add-apt-repository ppa:sftpgo/sftpgo
apt update

---

Installation de SFTPGo

apt install -y sftpgo

---

Vérification du service

systemctl status sftpgo

Résultat attendu :

• service actif (running) ;
• écoute par défaut sur le port 2022 pour SFTP.

---

Activation au démarrage

systemctl enable --now sftpgo

---

Fonctionnement du service

• le service tourne avec l’utilisateur système sftpgo ;
• UID typique : 995 ;
• GID typique : 987.

Vérification :

id sftpgo

---

Accès aux données

Par défaut, l’utilisateur sftpgo n’a accès à aucun dataset client.

Pour permettre l’accès aux données :

usermod -aG pleade sftpgo
systemctl restart sftpgo

Explication

• les données clients appartiennent au groupe pleade ;
• SFTPGo doit pouvoir lire/écrire dans ces répertoires ;
• l’ajout au groupe pleade permet cet accès.

⚠️ Important :

• il s’agit d’un accès technique (daemon), pas d’un utilisateur humain ;
• ne pas ajouter d’utilisateurs humains dans ce groupe pour des raisons de sécurité.

---

Vérification des accès aux datasets

Exemple :

namei -l /var/data/apbp-data/data/pleade

Conditions nécessaires :

• tous les répertoires traversés doivent être au minimum r-x ;
• les répertoires d’écriture doivent être rwx pour le groupe.

---

Droits recommandés

Pour les zones d’écriture :

chmod -R 775 /var/data/<client>-data/data/pleade
chmod -R 775 /var/data/<client>-data/data/projets

⚠️ Ne pas modifier :

• data-private (zone interne applicative) ;
• les répertoires système.

---

Répertoire technique des homes SFTPGo

Créer un répertoire dédié pour les chroot techniques :

mkdir -p /var/sftpgo-homes
chown sftpgo:sftpgo /var/sftpgo-homes
chmod 755 /var/sftpgo-homes

Puis, pour chaque client :

mkdir -p /var/sftpgo-homes/<client>
chown sftpgo:sftpgo /var/sftpgo-homes/<client>
chmod 755 /var/sftpgo-homes/<client>

Explication

• ces répertoires servent de racine technique pour SFTPGo ;
• ils restent vides ;
• les données réelles sont montées via des virtual folders.

---

Répertoire /srv/sftpgo

Par défaut, SFTPGo utilise le répertoire /srv/sftpgo pour :

• le stockage local des utilisateurs ;
• les sauvegardes internes.

Dans l’architecture eole3 :

• les données sont stockées dans /var/data/ (ZFS) ;
• les accès se font via des virtual folders ;
• les répertoires techniques sont dans /var/sftpgo-homes/.

Vérification

ls -la /srv/sftpgo
grep -R "/srv/sftpgo" /etc/sftpgo

Conclusion

Si le répertoire est vide et non utilisé :

rm -rf /srv/sftpgo

Recommandation

Adapter la configuration SFTPGo pour utiliser :

• /var/sftpgo-homes pour les homes techniques ;
• /var/lib/sftpgo pour les données internes.

Le répertoire /srv/sftpgo ne doit pas être utilisé dans une architecture basée sur ZFS et virtual folders.

À modifier dans : /etc/sftpgo/sftpgo.json

"users_base_dir": "/var/sftpgo-homes",
...
"backups_path": "/var/lib/sftpgo/backups"

Puis :

systemctl restart sftpgo

Organisation des données clients

Structure cible :

/var/data/<client>-data/
└── data/
    ├── pleade/
    ├── projets/
    └── data-private/

Règles :

• pleade : dépôt client principal ;
• projets : espace de travail client ;
• data-private : données internes (non exposées).

---

Bonnes pratiques

• ne jamais exposer data-private via SFTPGo ;
• limiter l’écriture aux seuls répertoires nécessaires ;
• conserver les droits Unix comme source de vérité ;
• utiliser SFTPGo comme couche de présentation et de contrôle.

--- Avant de lancer la modificatiopn des acl, on fait un backup des acl de chaque client stockées dans /root/acl_backups/

Audit apbp : ensemble globalement cohérent. La racine client et les arborescences preprod/prod/projets sont correctes. On observe en revanche des permissions historiques trop ouvertes sur pleade, files, images et plusieurs sous-répertoires (777 au lieu de droits plus stricts). Un écart notable est relevé sur pleade/preprod/iiif-datadir, appartenant à ad53:pleade alors qu’il se trouve dans l’arborescence du client apbp. Pas de blocage apparent, mais une normalisation des droits et propriétaires est nécessaire.

Problème : les acl ont été mal modifiées :

Restauration avec la commandes suivantes :

setfacl --restore=/root/acl-backups/ad64_before_rights_2026-04-10_143446.acl

apbp validé après correction du script 02_apply_client_rules.sh. Les propriétaires sont désormais corrects (apbp:pleade), les permissions sont homogènes et conformes à la politique attendue : BASE en 1775, racine pleade et niveau 1 en 3775, niveau 2 et projets en 2775. L’anomalie précédente sur les ownerships a disparu.

Interaction avec rsync eole2 → eole3

Le rsync synchronise :

/var/data/<client>-data/ → /var/data/<client>-data/data/

Options utilisées :

-aHAX --numeric-ids --delete-after

Conséquences :

• les fichiers sont synchronisés depuis eole2 ;
• les permissions, ACL et propriétaires peuvent être écrasés ;
• les fichiers absents côté eole2 peuvent être supprimés.

⚠️ Recommandation :

• désactiver le cron rsync avant toute modification des droits ;
• ou travailler hors des répertoires synchronisés.

---

Groupes SFTP

Les comptes clients doivent appartenir au groupe :

• eole3-sftp

Ce groupe est utilisé exclusivement pour appliquer les règles SSH suivantes :

Match Group eole3-sftp
    ChrootDirectory %h
    ForceCommand internal-sftp

Important :

• ne jamais utiliser le groupe pleade dans un bloc Match ;
• le groupe pleade sert uniquement à la gestion des droits sur les fichiers ;
• cette séparation permet de conserver des comptes administrateurs (ex : ajlsm) avec accès SSH complet.

---

Quotas SFTPGo

Par défaut, SFTPGo applique :

• Quota size = -1
• Quota files = -1

Signification :

• -1 = illimité

Recommandation :

• ne pas définir de quotas dans le template par défaut ;
• définir les quotas uniquement au cas par cas selon les besoins client ;
• éviter les conflits avec les quotas ZFS.

Règle sur le répertoire projets

Le répertoire /data/projets constitue un point d’entrée fixe.

Règle :

• le répertoire projets ne doit pas pouvoir être supprimé ;
• le répertoire projets ne doit pas pouvoir être déplacé ou renommé ;
• en revanche, son contenu interne est librement modifiable par le client.

Le client peut donc :

• créer des sous-répertoires ;
• déposer des fichiers ;
• remplacer des fichiers ;
• supprimer ou déplacer des éléments à l’intérieur de projets.

Cette règle est obtenue par :

• protection du répertoire parent ;
• propriété administrative du répertoire projets ;
• droits d’écriture accordés via le groupe pleade.

Gestion des quotas avec SFTPGo

SFTPGo permet de définir des quotas à deux niveaux :

1. Quota utilisateur

Défini dans "Disk quota and bandwidth limits".

• 0 = illimité
• valeur (ex : 250GB) = quota global utilisateur

2. Quota par virtual folder

• -1 = inclus dans le quota utilisateur
• 0 = illimité
• valeur = quota spécifique au dossier

Bonnes pratiques

• utiliser le quota utilisateur comme limite principale ;
• laisser les virtual folders à -1 pour mutualiser l’espace ;
• éviter de cumuler plusieurs quotas de virtual folders ;
• aligner les quotas SFTPGo avec les quotas ZFS.

Exemple :

• Quota utilisateur : 250GB
• /pleade : -1
• /projets : -1

→ le client dispose de 250GB au total, répartis librement.

Répertoire /srv/sftpgo

Par défaut, SFTPGo utilise le répertoire /srv/sftpgo pour :

• le stockage local des utilisateurs ;
• les sauvegardes internes.

Dans l’architecture eole3 :

• les données sont stockées dans /var/data/ (ZFS) ;
• les accès se font via des virtual folders ;
• les répertoires techniques sont dans /var/sftpgo-homes/.

Vérification

ls -la /srv/sftpgo
grep -R "/srv/sftpgo" /etc/sftpgo

Conclusion

Si le répertoire est vide et non utilisé :

rm -rf /srv/sftpgo

Recommandation

Adapter la configuration SFTPGo pour utiliser :

• /var/sftpgo-homes pour les homes techniques ;
• /var/lib/sftpgo pour les données internes.

Le répertoire /srv/sftpgo ne doit pas être utilisé dans une architecture basée sur ZFS et virtual folders.

Harmonisation des droits clients pour SFTPGo sur eole3

Objectif

Cette procédure a pour but d’harmoniser les droits Unix des répertoires clients afin de rendre le fonctionnement de SFTPGo :

• prévisible ;
• homogène ;
• réversible en cas de problème.

L’objectif n’est pas de remplacer les droits Unix par SFTPGo, mais de faire en sorte que :

• les droits Unix restent la base de vérité ;
• SFTPGo applique ensuite une couche logique cohérente par client.

---

Pourquoi cette harmonisation est nécessaire

Lors des tests avec SFTPGo, il est apparu que les arborescences clientes historiques étaient hétérogènes :

• certains répertoires étaient en 755 ;
• d’autres en 775 ;
• d’autres encore en 777 ;
• les propriétaires n’étaient pas homogènes ;
• certaines branches permettaient l’écriture, d’autres non.

Cela produisait des comportements incohérents pour les utilisateurs :

• dépôt possible dans certains sous-répertoires ;
• création de dossier refusée dans d’autres ;
• suppression possible ici, impossible là.

Exemple constaté :

• /projets fonctionnait correctement ;
• dans /pleade, certaines branches autorisaient l’écriture et d’autres non uniquement à cause des droits Unix.

La mise en place de SFTPGo a donc conduit à formaliser une doctrine Unix homogène.

---

Doctrine retenue

Répertoire pleade

Règles générales :

• Tous les fichiers : 664
• Tous les répertoires : 775
• Groupe : pleade

Restrictions structurelles :

• Niveau 1 (ex : internet, preprod, slecture) :
  • non supprimables ;
  • non déplaçables.

• Niveau 2 (ex : images, pdf, csv, etc.) :
  • non supprimables ;
  • non déplaçables.

Comportement attendu :

• les utilisateurs peuvent modifier le contenu ;
• ils ne peuvent pas casser la structure.

---

Répertoire projets

Règles générales :

• Répertoire racine :
  • non supprimable ;
  • non déplaçable.

• Contenu :
  • liberté totale pour les utilisateurs.

Droits :

• répertoires : 775
• fichiers : 664

---

Protection structurelle

La protection repose sur les bits Unix :

• sticky bit (t) → empêche suppression/déplacement
• setgid (g+s) → conserve le groupe pleade

---

Principe de mise en œuvre

La mise en conformité se fait client par client avec trois scripts :

• audit ;
• application des règles ;
• vérification.

---

1. Script d’audit

Fichier :

/opt/scripts_clients_sftpgo/01_audit_client.sh

Utilisation :

./01_audit_client.sh ad53

Ce script permet de :

• visualiser les droits existants ;
• identifier les incohérences ;
• vérifier la présence des répertoires pleade et projets ;
• détecter les ACL éventuelles.

Aucune modification n’est effectuée.

---

2. Script d’application des règles

Fichier :

/opt/scripts_clients_sftpgo/02_apply_client_rules.sh

Utilisation :

./02_apply_client_rules.sh ad53

Ce script applique :

• homogénéisation des droits :
  • dossiers en 775 ;
  • fichiers en 664 ;

• sécurisation de la structure :
  • sticky bit sur pleade et niveaux 1 ;
  • setgid pour conserver le groupe ;

• création de /projets si absent ;

• protection de la structure via :
  • chmod 3775 sur pleade ;
  • chmod 3775 sur niveau 1 ;
  • chmod 2775 sur niveau 2 ;
  • chmod 2775 sur projets ;
  • chmod 1775 sur le parent.

---

3. Script de vérification

Fichier :

/opt/scripts_clients_sftpgo/03_verify_client.sh

Utilisation :

./03_verify_client.sh ad53

Permet de vérifier :

• les droits appliqués ;
• la présence des bits t et g+s ;
• la cohérence globale.

---

Sauvegarde des ACL

Avant toute modification, une sauvegarde complète des ACL a été réalisée.

Emplacement :

/root/acl-backups/

Contenu :

• un backup global :

acl-backup-2026-04-09_1230.acl

• un backup compressé :

acl-backup-2026-04-09_1230_acl.tar.gz

• un backup par client :

ad53_before_rights_YYYY-MM-DD_HHMMSS.acl

---

Réversibilité

La restauration peut être faite :

Cas global

setfacl --restore=/root/acl-backups/acl-backup-2026-04-09_1230.acl

Cas par client

setfacl --restore=/root/acl-backups/ad53_before_rights_YYYY-MM-DD_HHMMSS.acl

---

Bonnes pratiques

• Toujours auditer avant modification ;
• Appliquer client par client ;
• Vérifier après chaque application ;
• Ne jamais modifier en masse sans backup ;
• Conserver les ACL de référence.

---

Audit apbp : ensemble globalement cohérent. La racine client et les arborescences preprod/prod/projets sont correctes. On observe en revanche des permissions historiques trop ouvertes sur pleade, files, images et plusieurs sous-répertoires (777 au lieu de droits plus stricts). Un écart notable est relevé sur pleade/preprod/iiif-datadir, appartenant à ad53:pleade alors qu’il se trouve dans l’arborescence du client apbp. Pas de blocage apparent, mais une normalisation des droits et propriétaires est nécessaire.

Conclusion

Cette approche permet :

• un comportement SFTP cohérent ;
• une base Unix propre ;
• une maintenance simplifiée ;
• une réversibilité totale en cas de problème.

La combinaison :

• droits Unix maîtrisés ;
• + SFTPGo

garantit un système robuste et prévisible.

1. !/usr/bin/env bash

set -euo pipefail IFS=$'\n\t'

CLIENT="${1:?Usage: $0 <client>}" BASE="/var/data/${CLIENT}-data/data" PLEADE="${BASE}/pleade"

1. Cas standard

PROJETS="${BASE}/projets"

1. Cas particulier ad64

if [ "$CLIENT" = "ad64" ] && [ -d "${BASE}/projet" ] && [ ! -d "${BASE}/projets" ]; then

 PROJETS="${BASE}/projet"

fi

if [ ! -d "$BASE" ]; then

 echo "ERREUR: base absente: $BASE"
 exit 1

fi

echo "=== APPLICATION REGLES CLIENT ${CLIENT} ==="

echo echo "--- TRAITEMENT PLEADE ---" if [ -d "$PLEADE" ]; then

 # 1. Uniformisation du contenu
 find "$PLEADE" -type d -exec chmod 775 {} \;
 find "$PLEADE" -type f -exec chmod 664 {} \;

 # 2. Racine pleade : non supprimable / non deplacable
 chown "${CLIENT}:pleade" "$PLEADE"
 chmod 3775 "$PLEADE"

 # 3. Niveau 1 : non supprimable / non deplacable
 find "$PLEADE" -mindepth 1 -maxdepth 1 -type d -exec chown "${CLIENT}:pleade" {} \;
 find "$PLEADE" -mindepth 1 -maxdepth 1 -type d -exec chmod 3775 {} \;

 # 4. Niveau 2 : groupe herite, sans sticky bit
 find "$PLEADE" -mindepth 2 -maxdepth 2 -type d -exec chown "${CLIENT}:pleade" {} \;
 find "$PLEADE" -mindepth 2 -maxdepth 2 -type d -exec chmod 2775 {} \;

 echo "OK: regles appliquees sur $PLEADE"

else

 echo "INFO: pas de repertoire pleade, rien a faire"

fi

echo echo "--- TRAITEMENT PROJETS ---" if [ ! -d "$PROJETS" ]; then

 echo "INFO: creation de $PROJETS"
 mkdir -p "$PROJETS"

fi

1. 1. Projets lui-meme : groupe herite

chown "${CLIENT}:pleade" "$PROJETS" chmod 2775 "$PROJETS"

1. 2. Protection du parent BASE pour figer projets

chown "${CLIENT}:pleade" "$BASE" chmod 1775 "$BASE"

1. 3. Contenu libre dans projets

find "$PROJETS" -mindepth 1 -type d -exec chmod 775 {} \; || true find "$PROJETS" -type f -exec chmod 664 {} \; || true

echo "OK: regles appliquees sur $PROJETS"

echo echo "=== FIN APPLICATION ${CLIENT} ==="

ad44-pleade        /var/data/ad44-data/data/pleade
ad44-projets       /var/data/ad44-data/data/projets

ad53-pleade        /var/data/ad53-data/data/pleade
ad53-projets       /var/data/ad53-data/data/projets

ad64-pleade        /var/data/ad64-data/data/pleade
ad64-projet        /var/data/ad64-data/data/projet

am-angers-pleade   /var/data/am-angers-data/data/pleade
am-angers-projets  /var/data/am-angers-data/data/projets

apbp-pleade        /var/data/apbp-data/data/pleade
apbp-projets       /var/data/apbp-data/data/projets

bm-rouen-pleade    /var/data/bm-rouen-data/data/pleade
bm-rouen-projets   /var/data/bm-rouen-data/data/projets

canigo-pleade      /var/data/canigo-data/data/pleade
canigo-projets     /var/data/canigo-data/data/projets

cdf-pleade         /var/data/cdf-data/data/pleade
cdf-projets        /var/data/cdf-data/data/projets

cnd-pleade         /var/data/cnd-data/data/pleade
cnd-projets        /var/data/cnd-data/data/projets

demo-v4-pleade     /var/data/demo-v4-data/data/pleade
demo-v4-projets    /var/data/demo-v4-data/data/projets

drac-ge-pleade     /var/data/drac-ge-data/data/pleade
drac-ge-projets    /var/data/drac-ge-data/data/projets

ens-lyon-pleade    /var/data/ens-lyon-data/data/pleade
ens-lyon-projets   /var/data/ens-lyon-data/data/projets

formation0-pleade  /var/data/formation0-data/data/pleade
formation0-projets /var/data/formation0-data/data/projets

formation1-pleade  /var/data/formation1-data/data/pleade
formation1-projets /var/data/formation1-data/data/projets

formation2-pleade  /var/data/formation2-data/data/pleade
formation2-projets /var/data/formation2-data/data/projets

formation3-pleade  /var/data/formation3-data/data/pleade
formation3-projets /var/data/formation3-data/data/projets

formation4-pleade  /var/data/formation4-data/data/pleade
formation4-projets /var/data/formation4-data/data/projets

ftp-ajlsm-pleade   /var/data/ftp-ajlsm-data/data/pleade
ftp-ajlsm-projets  /var/data/ftp-ajlsm-data/data/projets

module-pleade-pleade   /var/data/module-pleade-data/data/pleade
module-pleade-projets  /var/data/module-pleade-data/data/projets

msh-dijon-pleade   /var/data/msh-dijon-data/data/pleade
msh-dijon-projets  /var/data/msh-dijon-data/data/projets

pleade.com-pleade  /var/data/pleade.com-data/data/pleade
pleade.com-projets /var/data/pleade.com-data/data/projets

port-dunkerque-pleade   /var/data/port-dunkerque-data/data/pleade
port-dunkerque-projets  /var/data/port-dunkerque-data/data/projets

siges-pleade       /var/data/siges-data/data/pleade
siges-projets      /var/data/siges-data/data/projets

test-ajlsm-pleade  /var/data/test-ajlsm-data/data/pleade
test-ajlsm-projets /var/data/test-ajlsm-data/data/projets

test-ftp-pleade    /var/data/test-ftp-data/data/pleade
test-ftp-projets   /var/data/test-ftp-data/data/projets

Conclusion

L’installation de SFTPGo repose sur :

• un service système dédié (sftpgo) ;
• un accès contrôlé aux données via le groupe pleade ;
• une séparation claire entre :

 * stockage réel (ZFS) ;
 * exposition logique (SFTPGo).

La configuration des accès utilisateurs se fait ensuite via l’interface Web de SFTPGo.