Logo Khaganat

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
fr:ssh [2025/10/23 08:38] zatalyzfr:ssh [2025/11/16 10:12] (Version actuelle) – [SFTP] C'est un détail mais je viens d'y passer une heure zatalyz
Ligne 338: Ligne 338:
 Après 5 "ping" sans réponse, la session sera fermée. Donc potentiellement au bout de 15 minutes.  Après 5 "ping" sans réponse, la session sera fermée. Donc potentiellement au bout de 15 minutes. 
  
-Cela évite de laisser ouverte des sessions fantômes. Cela peut être paramétré plus court, mais ce genre de délai évite d'éjecter s'il y a juste quelques pertes de paquets dans la connexion. Par ailleurs, d'autres mécanismes vont déconnecter les sessions ssh inactives (dont les pare-feu).+Cela évite de laisser ouverte des sessions fantômes. Cela peut être paramétré plus court ou plus long, mais ce genre de délai évite d'éjecter s'il y a juste quelques pertes de paquets dans la connexion, tout en étant plutôt très sécurisé. Par ailleurs, d'autres mécanismes vont déconnecter les sessions ssh inactives (dont les pare-feu). Ces paramètres sont à adapter suivant le type de serveur :  
 +  * Serveur destiné à recevoir des gros fichiers (rsync, scp), avec des tunnels, ou des scripts : prévoir plus long, par exemple ''ClientAliveInterval 15m'' et ''ClientAliveCountMax 3'' (45 minutes au total). 
 +  * Serveur sensibles, et quand on a tendance à oublier qu'on est co et laisser la session ouverte : ''ClientAliveInterval 3m'' et ''ClientAliveCountMax 5'' est correct. 
 +  * Notez que lors des grosses maj (où il se passe du temps sans que le sysadmin n'agisse), nous conseillons de réaliser les opérations avec tmux/screen, ce qui permet de se reconnecter à la session même si on a été déconnecté de ssh.  
 === Comportement à la connexion, environnement === === Comportement à la connexion, environnement ===
   PrintLastLog yes   PrintLastLog yes
Ligne 351: Ligne 355:
   AcceptEnv LANG LC_*   AcceptEnv LANG LC_*
 Cela permet à l'utilisateur de passer avec ses propres variables d'environnement mais uniquement pour la langue. ''AcceptEnv'' est à manier avec précaution, mais appliqué ici uniquement à la question linguistique, cela ne devrait pas être un problème. Cela permet à l'utilisateur de passer avec ses propres variables d'environnement mais uniquement pour la langue. ''AcceptEnv'' est à manier avec précaution, mais appliqué ici uniquement à la question linguistique, cela ne devrait pas être un problème.
- 
-  Subsystem sftp /usr/lib/openssh/sftp-server 
-Appelle un daemon pour gérer certains aspects, ici sftp. À ne laisser que si sftp est réellement utilisé et bien paramétré, sinon cela peut ouvrir des failles. 
  
 === Redirections et accès à distance === === Redirections et accès à distance ===
Ligne 367: Ligne 368:
   PermitTunnel no   PermitTunnel no
 Là aussi l'option par défaut est en théorie suffisante, mais autant la renforcer. Dans de rares cas, on a besoin de faire des tunnels, mais alors mieux vaut les permettre explicitement avec un ''Match Group''/''Match User''. Là aussi l'option par défaut est en théorie suffisante, mais autant la renforcer. Dans de rares cas, on a besoin de faire des tunnels, mais alors mieux vaut les permettre explicitement avec un ''Match Group''/''Match User''.
 +
 +=== SFTP ===
 +SFTP est un cas particulier. Ce protocole est très utile pour transférer des fichiers dans un environnement plus simple à sécuriser. La plupart des serveurs n'en ont cependant pas besoin : on utilise rsync, pas besoin de plus. 
 +
 +Donc, cette partie est totalement facultative ! 
 +
 +Dans le cas où vous voulez permettre à des utilisatrices de manipuler des fichiers et dossiers dans leur home, il faudra les déclarer dans le groupe "sftpuser", puis ajouter ceci à ''sshd_config.d/sftp.config''
 +<code>
 +Subsystem sftp internal-sftp -l INFO -f AUTH
 +
 +Match Group wheel
 +    ChrootDirectory none
 +    ForceCommand none
 +    PermitTTY yes
 +    PermitUserRC yes
 +    
 +Match Group sftpusers
 +    ChrootDirectory /home/%u
 +    ForceCommand internal-sftp -d /sftp
 +    PermitTTY no
 +    PermitUserRC no
 +    # Autoriser une connexion plus longue pour permettre de transférer des fichiers 
 +    ClientAliveInterval 15m
 +    ClientAliveCountMax 3
 +</code>
 +  * ''Subsystem sftp internal-sftp'' permet d'utiliser sftp via le module interne (directement fourni par SSH). Il faut cependant explicitement demander les logs lors de son usage (ici ''-l INFO -f AUTH'', comme les logs par défaut de SSH). 
 +  * L'ordre des "Match Group" est primordial. Ici, on s'assure que les sysadmins (wheel) continueront à avoir accès à un vrai shell en se connectant, même si elles font aussi partie du groupe ''sftpusers''
 +  * ''ChrootDirectory'' indique "où" le sous-sytème sftp est chrooté. Cela permet d'isoler les utilisatrices lors de leur connexion, et de leur éviter de bidouiller chez la voisine.
 +  * ''ForceCommand internal-sftp'' : lors de la connexion, la seule chose autorisée est l'usage de sftp. Et c'est pourquoi on précise "none" pour les sysadmin !
 +    * J'ajoute la commande ''-d /sftp'' qui force en plus l'utilisatrice à atterrir dans le sous-dossier ''sftp''. Voir le détail de pourquoi plus bas !
 +  * ''PermitTTY'' s'assurer explicitement de l'accès (ou non) au shell. Bien qu'il y aie peu de risque de contourner sftp, mais je suis parano. On ne donne pas d'accès au shell complet "comme ça", c'est ce qui permet par mal d'escalade de privilèges, dès qu'il y a une faille dans un logiciel.
 +  * ''PermitUserRC'' : à ''no'' pour nos sftpusers ; cela permet d'utiliser ''~/.ssh/rc'', lequel permet de lancer des commandes automatiques à la connexion. Une faille évidente si on le laisse libre d'accès.
 +  * On permet enfin une connexion plus longues avec ''ClientAliveInterval'' et ''ClientAliveCountMax'' sinon les gens se feront déconnecter en essayant d'envoyer leurs photos depuis une vieille connexion 2G pourrie. 
 +
 +À noter : le dossier paramétré par ChrootDirectory doit être possédé par root pour que tout fonctionne. L'utilisatrice n'auras pas la possibilité d'ajouter des dossiers/fichiers à la racine de son home (pas de ''/home/gudule/modossier'' par exemple) mais le pourra dans les sous-dossiers (''/home/gudule/web/monsite'' et ''/home/gudule/modossier''. Comme cela peut être un peu déstabilisant, on peut aussi directement forcer l'utilisatrice à être dans un sous-dossier (''/home/gudule/sftp/'', dont en théorie elle ne pourra pas sortir. Et elle ne pourra pas non plus bidouiller les fichiers cachés du home que Linux aime lire et interpréter. En soit, c'est donc aussi simple de forcer Gudule à rester dans ce dossier "sftp"
 +
 +Un autre point important : ajoutez sftpusers à la directive ''AllowGroups'' sinon... ça ne marchera pas. 
 +  AllowGroups wheel sftpusers
 +
 +
 +Voir aussi [[https://man.openbsd.org/sshd_config.5#Subsystem]].
  
 === Exemple de fichier sshd_config === === Exemple de fichier sshd_config ===
Ligne 410: Ligne 452:
 PermitUserEnvironment no PermitUserEnvironment no
 AcceptEnv LANG LC_* AcceptEnv LANG LC_*
-# Seulement si sftp est actif et bien paramétré 
-# Subsystem sftp /usr/lib/openssh/sftp-server 
  
 # Redirections et accès à distance # Redirections et accès à distance
Ligne 418: Ligne 458:
 GatewayPorts no GatewayPorts no
 PermitTunnel no PermitTunnel no
 +
 +# Uniquement si on permet sftp !
 +Subsystem sftp internal-sftp -l INFO -f AUTH
 +
 +Match Group wheel
 +    ChrootDirectory none
 +    ForceCommand none
 +    PermitTTY yes
 +    PermitUserRC yes
 +    
 +Match Group sftpusers
 +    ChrootDirectory /home/%u
 +    ForceCommand internal-sftp -d /sftp
 +    PermitTTY no
 +    PermitUserRC no
 +    # Autoriser une connexion plus longue pour permettre de transférer des fichiers 
 +    ClientAliveInterval 15m
 +    ClientAliveCountMax 3
 </code> </code>
  
CC Attribution-Share Alike 4.0 International Driven by DokuWiki
fr/ssh.1761208681.txt.gz · Dernière modification : de zatalyz

Licences Mentions légales Accueil du site Contact Inclusion