Doctrine des accès sur eole3 - Historique des versions

Jlarvers : /* 3. Comptes clients SFTP, par exemple ad53 */

2026-04-10T10:05:53Z

3. Comptes clients SFTP, par exemple ad53

← Version précédente		Version du 10 avril 2026 à 10:05
Ligne 62 :		Ligne 62 :
	Le compte '''ubuntu''' sert d’accès d’administration, mais l’administration effective se fait ensuite en '''root'''.		Le compte '''ubuntu''' sert d’accès d’administration, mais l’administration effective se fait ensuite en '''root'''.

	== 3. Comptes clients SFTP~~, par exemple ad53~~ ==		== 3. Comptes clients SFTP ==

	=== Rôle ===		=== Rôle ===

	Un compte comme '''ad53''' est un compte de dépôt ou de récupération de fichiers, en '''SFTP uniquement'''.		Un compte comme '''ad53''' est un compte de dépôt ou de récupération de fichiers, en '''SFTP uniquement'''.

			=== Fonctionnement ===

			Les comptes clients sont :
			* membres du groupe '''pleade''' (logique métier) ;
			* membres du groupe '''eole3-sftp''' (confinement SSH).

			=== Configuration SSH associée ===

			<pre>
			Match Group eole3-sftp
			ChrootDirectory %h
			ForceCommand internal-sftp -P setstat,fsetstat
			</pre>

	=== Ce qu’il peut faire ===		=== Ce qu’il peut faire ===

	* se connecter en SFTP ;		* se connecter en SFTP ;
	* accéder à son ~~espace propre~~ ;		* accéder à son dataset ;
	* déposer ou récupérer des fichiers dans ~~son répertoire de travail~~.		* déposer et récupérer des fichiers dans les zones prévues.

	=== Ce qu’il ne peut pas faire ===		=== Ce qu’il ne peut pas faire ===
	* ouvrir une session SSH interactive ;
	* lancer un shell ;
	* accéder aux autres espaces clients ;
	* intervenir sur la configuration du serveur.

	~~=== Fonctionnement ===~~		* ouvrir une session SSH ;
			* exécuter des commandes ;
			* sortir de son chroot ;
			* accéder aux autres clients.

	~~Les comptes clients sont rattachés au groupe '''pleade''' et sont soumis à la règle SSH suivante :~~		=== Droits réels ===

	~~<pre>~~		Les permissions ne sont pas gérées par SSH mais par les droits Unix :
	~~Match Group pleade~~
	~~ChrootDirectory /data/ftp/%u~~
	~~ForceCommand internal-sftp~~
	~~AllowTcpForwarding no~~
	~~X11Forwarding no~~
	~~</pre>~~

	~~=== Explication ===~~		* écriture autorisée dans :
			* <code>/data/pleade</code>
			* <code>/data/projets</code>

	~~Cette configuration impose un environnement strictement limité pour les comptes clients~~ :		* écriture interdite dans :
	* ~~'''ChrootDirectory''' enferme l’utilisateur dans son répertoire ;~~		* <code>/data</code>
	* ~~'''ForceCommand internal~~-~~sftp''' empêche l’accès à un shell ;~~		* <code>/data/data-private</code>
	* les redirections réseau sont désactivées.

	=== Conclusion ===		=== Conclusion ===

	Les comptes SFTP sont ~~volontairement~~ limités à un usage de dépôt ~~et de récupération de fichiers~~, ~~sans possibilité d’interaction avec le système~~.		Les comptes SFTP sont strictement limités à un usage de dépôt, en respectant les droits Unix existants.

	== 4. Comptes techniques nominatifs ==		== 4. Comptes techniques nominatifs ==

Jlarvers : /* Doctrine des accès sur eole3 */

2026-04-08T14:39:13Z

Doctrine des accès sur eole3

← Version précédente		Version du 8 avril 2026 à 14:39
Ligne 2 :		Ligne 2 :
	[[category:eole3]]		[[category:eole3]]
	== Principe général ==		== Principe général ==
			Voir aussi : [[EOLE3_—_Administration,_maintenance_et_flux_de_données]]

	Sur '''eole3''', il faut distinguer clairement trois types d’accès :		Sur '''eole3''', il faut distinguer clairement trois types d’accès :

Jlarvers le 8 avril 2026 à 14:32

2026-04-08T14:32:57Z

← Version précédente		Version du 8 avril 2026 à 14:32
Ligne 1 :		Ligne 1 :
	= Doctrine des accès sur eole3 =		= Doctrine des accès sur eole3 =
			[[category:eole3]]
	== Principe général ==		== Principe général ==

Jlarvers le 8 avril 2026 à 12:43

2026-04-08T12:43:29Z

Voir les modifications

Jlarvers : /* Fonctionnement */

2026-04-08T12:41:25Z

Fonctionnement

← Version précédente		Version du 8 avril 2026 à 12:41
Ligne 80 :		Ligne 80 :
	=== Fonctionnement ===		=== Fonctionnement ===
	Match Group pleade		Match Group pleade
	ChrootDirectory /data/ftp/%u		ChrootDirectory /data/ftp/%u
	ForceCommand internal-sftp		ForceCommand internal-sftp
	AllowTcpForwarding no		AllowTcpForwarding no
	X11Forwarding no		X11Forwarding no

	=== Explication ===		=== Explication ===

Jlarvers : /* Fonctionnement */

2026-04-08T12:40:59Z

Fonctionnement

← Version précédente		Version du 8 avril 2026 à 12:40
Ligne 79 :		Ligne 79 :

	=== Fonctionnement ===		=== Fonctionnement ===
	Match Group pleade		Match Group pleade
	ChrootDirectory /data/ftp/%u		ChrootDirectory /data/ftp/%u
	ForceCommand internal-sftp		ForceCommand internal-sftp

Jlarvers : Page créée avec « = Doctrine des accès sur eole3 = == Principe général == Sur ‘’‘eole3’’’, il faut distinguer clairement trois types d’accès : • les comptes d’admin... »

2026-04-08T12:40:33Z

Page créée avec « = Doctrine des accès sur eole3 = == Principe général == Sur ‘’‘eole3’’’, il faut distinguer clairement trois types d’accès : • les comptes d’admin... »

Nouvelle page

= Doctrine des accès sur eole3 =

== Principe général ==

Sur ‘’‘eole3’’’, il faut distinguer clairement trois types d’accès :
• les comptes d’administration ;
• les comptes clients de dépôt en SFTP ;
• les comptes techniques nominatifs utilisés pour le travail en SSH.

Cette distinction est importante afin d’éviter de mélanger les usages et de recréer des accès incohérents au fil des besoins.

== 1. Compte root ==

=== Rôle ===

Le compte ‘’‘root’’’ est le compte d’administration système.

=== Ce qu’il peut faire ===
• administrer entièrement le serveur ;
• gérer les datasets ZFS ;
• créer, modifier ou supprimer des arborescences ;
• corriger les droits et propriétaires ;
• lancer les scripts de synchronisation ;
• intervenir dans tous les répertoires clients ;
• modifier la configuration SSH et SFTP.

=== Exemples ===
• créer un dataset ZFS pour un nouveau client ;
• lancer la synchronisation provisoire entre eole2 et eole3 ;
• corriger les droits sur un répertoire client ;
• consulter les logs système ;
• modifier la configuration de SSH.

=== Conclusion ===

Le compte ‘’‘root’’’ est réservé à l’exploitation, à la maintenance, aux migrations et au dépannage.

== 2. Compte ubuntu ==

=== Rôle ===

Le compte ‘’‘ubuntu’’’ est le compte d’entrée d’administration distante.

=== Ce qu’il peut faire ===
• se connecter en SSH avec clé ;
• devenir root via sudo ;
• servir de point d’entrée pour l’administration distante.

=== Ce qu’il ne doit pas être ===
• ce n’est pas un compte client ;
• ce n’est pas un compte de dépôt ;
• ce n’est pas un compte métier.

=== Exemples ===
• connexion SSH initiale au serveur ;
• utilisation de sudo pour passer root ;
• intervention d’administration courante.

=== Conclusion ===

Le compte ‘’‘ubuntu’’’ sert d’accès d’administration, mais l’administration effective se fait ensuite en ‘’‘root’’’.

== 3. Comptes clients SFTP, par exemple ad53 ==

=== Rôle ===

Un compte comme ‘’‘ad53’’’ est un compte de dépôt ou de récupération de fichiers, en ‘’‘SFTP uniquement’’’.

=== Ce qu’il peut faire ===
• se connecter en SFTP ;
• accéder à son espace propre ;
• déposer ou récupérer des fichiers dans son répertoire de travail.

=== Ce qu’il ne peut pas faire ===
• ouvrir une session SSH interactive ;
• lancer un shell ;
• accéder aux autres espaces clients ;
• intervenir sur la configuration du serveur.

=== Fonctionnement ===
Match Group pleade
ChrootDirectory /data/ftp/%u
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no

=== Explication ===

Cette configuration impose un environnement strictement limité pour les comptes clients :
* ‘’‘ChrootDirectory’’’ enferme l’utilisateur dans son répertoire ;
* ‘’‘ForceCommand internal-sftp’’’ empêche l’accès à un shell ;
* les redirections réseau sont désactivées.

=== Conclusion ===

Les comptes SFTP sont volontairement limités à un usage de dépôt et de récupération de fichiers, sans possibilité d’interaction avec le système.

== 4. Comptes techniques nominatifs ==

=== Rôle ===

Les comptes techniques nominatifs sont des comptes individuels utilisés par les administrateurs pour intervenir en SSH.

=== Ce qu’ils peuvent faire ===
* se connecter en SSH avec clé ;
* exécuter des commandes d’administration via sudo ;
* intervenir sur les données selon les droits attribués.

=== Ce qu’ils ne doivent pas faire ===
* être utilisés comme comptes de service ;
* être partagés entre plusieurs personnes ;
* remplacer le compte ‘’‘root’’’ pour les opérations critiques.

=== Bonnes pratiques ===
* un compte par personne ;
* authentification par clé uniquement ;
* traçabilité des actions via les logs ;
* utilisation de sudo plutôt que connexion directe en root si nécessaire.

=== Exemples ===
* connexion SSH nominative ;
* intervention sur un dataset client ;
* analyse de logs ;
* opérations de maintenance courante.

=== Conclusion ===

Les comptes nominatifs permettent d’assurer la traçabilité des actions tout en conservant un bon niveau de sécurité.

== Conclusion générale ==

La séparation entre ‘’‘root’’’, ‘’‘ubuntu’’’, les comptes SFTP et les comptes nominatifs est essentielle pour garantir :
* la sécurité du système ;
* la cohérence des droits ;
* la simplicité de maintenance ;
* la traçabilité des interventions.

Toute dérogation à ces principes doit rester exceptionnelle, justifiée et documentée.

Doctrine des accès sur eole3 - Historique des versions

Jlarvers : /* 3. Comptes clients SFTP, par exemple ad53 */

Jlarvers : /* Doctrine des accès sur eole3 */

Jlarvers le 8 avril 2026 à 14:32

Jlarvers le 8 avril 2026 à 12:43

Jlarvers : /* Fonctionnement */

Jlarvers : /* Fonctionnement */

Jlarvers : Page créée avec « = Doctrine des accès sur eole3 = == Principe général == Sur ‘’‘eole3’’’, il faut distinguer clairement trois types d’accès : • les comptes d’admin... »

Jlarvers : /* 3. Comptes clients SFTP, par exemple ad53 */

Jlarvers : /* Doctrine des accès sur eole3 */

Jlarvers : /* Fonctionnement */

Jlarvers : /* Fonctionnement */

Jlarvers : Page créée avec « = Doctrine des accès sur eole3 = == Principe général == Sur ‘’‘eole3’’’, il faut distinguer clairement trois types d’accès : • les comptes d’admin... »