Gestion accès SFTP sur eole3

Gestion des accès SFTP sur eole3

Objectif

Mettre en place un accès SFTP sécurisé et cloisonné pour les clients, tout en conservant un accès SSH complet pour les administrateurs (ex : utilisateur ajlsm).

Contraintes :

• 1 client = 1 répertoire dédié
• accès limité (chroot) pour les clients SFTP
• accès SSH complet pour les admins
• compatibilité avec ZFS
• gestion des droits pour permettre lecture/écriture multi-utilisateurs

---

Architecture existante

• Données stockées sur ZFS :

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

• Exemple :

/var/data/ad53-data/data/
/var/data/pleade.com-data/data/

• Organisation interne :
• data-private : ajlsm:ajlsm
• projets : <client>:pleade
• pleade : <client>:pleade
• autres dossiers selon besoin

---

Problématique initiale

• Tous les utilisateurs étaient dans le groupe pleade
• Configuration SSH :

Match Group pleade
    ChrootDirectory %h
    ForceCommand internal-sftp

Conséquence :

• l'utilisateur admin ajlsm était forcé en SFTP
• impossible d'avoir un accès SSH normal

---

Solution : séparation des groupes

Création d’un nouveau groupe dédié SFTP :

groupadd eole3-sftp

Principe :

• groupe pleade → usage applicatif
• groupe eole3-sftp → accès SFTP uniquement

---

Configuration des utilisateurs

Utilisateurs SFTP

Exemple :

usermod -aG eole3-sftp pleadecom

Résultat :

• chroot SFTP actif
• pas d’accès SSH

Utilisateur admin

id ajlsm
uid=1025(ajlsm) gid=1000(pleade)

• NE DOIT PAS être dans eole3-sftp
• conserve accès SSH complet

---

Configuration SSH

Fichier :

/etc/ssh/sshd_config.d/20-eole3-sftp.conf

Contenu :

Match Group eole3-sftp
    ChrootDirectory %h
    ForceCommand internal-sftp -d /data
    AllowTcpForwarding no
    PermitTunnel no
    X11Forwarding no
    PasswordAuthentication yes

Configuration existante conservée :

Match Group pleade
    (à supprimer ou ne plus utiliser pour SFTP)

---

Vérification de la configuration

sshd -t
systemctl reload ssh

Test :

sshd -T -C user=pleadecom,addr=127.0.0.1

Résultat attendu :

• chroot actif
• internal-sftp actif

---

Structure des répertoires SFTP

Exemple :

/var/data/pleade.com-data/
    └── data/

Contraintes OpenSSH :

• répertoire chroot :

chown root:root /var/data/pleade.com-data
chmod 755 /var/data/pleade.com-data

• données accessibles :

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

---

Gestion des droits

Dossiers

chmod 2775 <dir>

• 2 = setgid
• héritage du groupe

Fichiers

chmod 664 <file>

Groupe

• groupe principal : pleade
• utilisateurs ajoutés au groupe :

usermod -aG pleade pleadecom

---

Problème rencontré : overwrite SFTP

Symptôme :

put test.pdf → Permission denied

Mais :

put test.pdf test2.pdf → OK

---

Explication

SFTP (OpenSSH) :

• overwrite = ouverture avec O_TRUNC
• nécessite droits sur le fichier existant

Cas bloquant :

-rw-r--r-- (644)

→ seul le propriétaire peut modifier

---

Solution retenue

Uniformiser les droits :

find /var/data -type f -exec chmod 664 {} ;
find /var/data -type d -exec chmod 2775 {} ;

---

Option avancée : ACL (avec rollback)

Sauvegarde

getfacl -R /var/data > /root/acl-backups/backup.acl

Application ciblée

setfacl -R -m g:pleade:rwX /var/data/pleade.com-data/data
setfacl -R -d -m g:pleade:rwX /var/data/pleade.com-data/data

Restauration

setfacl --restore=/root/acl-backups/backup.acl

---

Bonnes pratiques

• ne pas utiliser chmod 777
• privilégier :

 * 664 pour fichiers
 * 2775 pour dossiers

• utiliser ACL uniquement si nécessaire
• tester sur un client avant généralisation

---

Conclusion

La solution repose sur :

• séparation des groupes :

 * pleade (applicatif)
 * eole3-sftp (accès SFTP)

• configuration SSH dédiée
• gestion rigoureuse des droits Unix
• compatibilité avec ZFS

Résultat :

• accès SFTP fonctionnel
• overwrite possible
• isolation des clients
• accès admin préservé

---