Différences

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

--- fr:ssh [2025/05/07 16:47] – mlkem768x25519-sha256 un peu trop khantique zatalyz
+++ fr:ssh [2025/11/16 10:12] (Version actuelle) – [SFTP] C'est un détail mais je viens d'y passer une heure zatalyz
@@ Ligne 253: / Ligne 253: @@
 === Chiffrement et algorithmes ===
   HostKey /etc/ssh/ssh_host_ed25519_key
+  HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
 Cela force à ce que seules les clés ed25519 soient présentées, valides et utilisables. Il s'agit de la clé que le **serveur** présente aux clients (aucun rapport avec le fait que les clients utilisent leur clé ed25519 pour se connecter).
 <WRAP center round info 100%>
-Version Bookworm (version openssh 1:9.2p1-2+deb12u5)
+> Les protocoles d'échange de clés sont basés sur les travaux post-quantiques, disponibles uniquement à partir d'une certaine version d'OpenSSH.
+Si vous avez Openssh avec une version supérieure à 9.9 :
+<code>KexAlgorithms mlkem768x25519-sha256
+</code>
+Pour les versions plus anciennes, comme Bookworm (version openssh 1:9.2p1-2+deb12u5), on peut utiliser d'autres versions.
 <code>KexAlgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com
-Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
-MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
 </code>
-Si vous avez openssh > 1:9.9p1-1
+À terme, il faudrait mieux n'avoir que ''mlkem768x25519-sha256''. Cependant, en période de transition, vous pouvez autoriser les trois algorithmes (certain des sysadmins se connectent peut-être depuis une version stable/oldstable de debian !
-<code>KexAlgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,mlkem768x25519-sha256
-Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
+<code>KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com</code>
+Plus d'informations sur [[https://rodolphe.breard.tf/article/ma-config-ssh/]].
+</WRAP>
+Pour le reste des protocoles d'échanges :
+<code>Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
 MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
 </code>
-> Les protocoles d'échange de clés sont basés sur les travaux post-quantiques, disponibles uniquement à partir d'une certaine version d'OpenSSH.
-</WRAP>
 Ajoutez ces lignes pour préciser les algorithmes acceptés et leur ordre de préférence lors de l'utilisation de SSH. Pour les protocoles, c'est assez compliqué, mais on a la chance d'avoir un mordu de chiffrement dans nos rangs alors : suivez les recommandations de Tycho, sauf si vous êtes en mesure de lui démontrer qu'il y a mieux.
@@ Ligne 329: / Ligne 338: @@
 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 ===
   PrintLastLog yes
@@ Ligne 342: / Ligne 355: @@
   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.
-  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 ===
@@ Ligne 353: / Ligne 363: @@
 ''X11Forwarding'' sert à afficher graphiquement sur sa machine locale ce qui se passe sur le serveur distant. En dehors de quelques cas particuliers, ça n'a aucun intérêt puisque vous allez agir via la console. De plus, les interfaces graphiques viennent avec leurs propres failles (forcément un logiciel de plus c'est plus de risque de failles, et avec X11 il y a de quoi s'amuser), donc... on désactive. Dans le cas où ce serait nécessaire, il faudra ajouter l'option ''ForwardX11Trusted no'' qui en limitera les privilèges.
+  GatewayPorts no
+C'est l'option par défaut, mais comme souvent la déclarer explicitement évite de se faire surprendre. Cela évite qu'une machine distante puisse se connecter sur un port redirigé par le client. Vous avez peut-être un service sur le port 8800, mais vous demandez l'accès "public" depuis le port 80 (avec proxy etc) ; mieux vaut éviter que les bots le teste sur son port interne.
+  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''.
+=== 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 ===
@@ Ligne 367: / Ligne 423: @@
 # Chiffrement et algorithmes
 HostKey /etc/ssh/ssh_host_ed25519_key
-KexAlgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com
+HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
+KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com
 Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
 MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
@@ Ligne 395: / Ligne 452: @@
 PermitUserEnvironment no
 AcceptEnv LANG LC_*
-# Seulement si sftp est actif et bien paramétré
-# Subsystem sftp /usr/lib/openssh/sftp-server
 # Redirections et accès à distance
 AllowTcpForwarding no
 X11Forwarding no
+GatewayPorts 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>