Différences

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

--- fr:ssh [2025/05/07 11:27] – [Paramétrer sshd_config] Mise à jour de la doc 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 239: / Ligne 239: @@
-Le fichier à modifier est ''/etc/ssh/sshd_config''.
+Le fichier à modifier est dans ''/etc/ssh/sshd_config.d/''. Il est préférable de laisser le ''/etc/ssh/sshd_config'' de base, qui doit inclure tous les fichiers situés dans ''/etc/ssh/sshd_config.d/''. Vérifiez que /etc/ssh/sshd_config inclue bien les fichiers de ''sshd_config.d'', puis créez par exemple ''/etc/ssh/sshd_config.d/myssh''
 === Protocole de base ===
@@ Ligne 251: / Ligne 251: @@
 Cela garantit que le serveur vérifie les modes et droits des fichiers de l'utilisateur avant de se connecter.
-=== Clés hôtes (identité du serveur) ===
+=== 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).
-=== Chiffrement et algorithmes ===
+<WRAP center round info 100%>
-<code>KexAlgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,mlkem768x25519-sha256
+> Les protocoles d'échange de clés sont basés sur les travaux post-quantiques, disponibles uniquement à partir d'une certaine version d'OpenSSH.
-Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
+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
+</code>
+À 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 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
-PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com
 </code>
 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.
+  PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com
 Notez que ''PubkeyAcceptedAlgorithms'' tel que paramétré va forcer les utilisatrices à se connecter avec des clés ed25519 : les RSA et autres, c'est fini !
@@ Ligne 311: / Ligne 331: @@
   LoginGraceTime 30
 Temps en secondes pour saisir son mot de passe. En fait, 30 secondes, c'est plutôt long, même avec une passphrase un peu conséquente. D'autant plus qu'il est possible d'utiliser l'agent ssh si on s'authentifie par clef, donc c'est encore plus rapide, à moins d'avoir d'autres facteurs de ralentissement, comme par exemple un réseau congestionné.
+  ClientAliveInterval 3m
+Toutes les 3 minutes, la session ssh enverra un "ping" au client pour vérifier s'il est toujours présent.
+  ClientAliveCountMax 5
+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 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 ===
@@ Ligne 324: / 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 336: / 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
-=== Exemple de fichier sshd_config ===
+Match Group wheel
+    ChrootDirectory none
+    ForceCommand none
-Voici à quoi peut ressembler votre fichier ''/etc/ssh/sshd_config''. Adaptez les quelques points à personnaliser.
+    PermitTTY yes
+    PermitUserRC yes
-<code txt ssh_config>
-#Port 22
+Match Group sftpusers
-Protocol 2
+    ChrootDirectory /home/%u
-Ciphers aes256-ctr,aes192-ctr,aes128-ctr
+    ForceCommand internal-sftp -d /sftp
-MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
+    PermitTTY no
+    PermitUserRC no
-PermitRootLogin no
+    # Autoriser une connexion plus longue pour permettre de transférer des fichiers
-StrictModes yes
+    ClientAliveInterval 15m
+    ClientAliveCountMax 3
-PasswordAuthentication no
-KbdInteractiveAuthentication no
-PubkeyAuthentication yes
-UsePAM yes
-PermitEmptyPasswords no
-MaxAuthTries 6
-LoginGraceTime 30
-AllowGroups wheel
-AllowTcpForwarding no
-X11Forwarding no
-PrintLastLog yes
-PrintMotd no
-AcceptEnv LANG LC_*
-Subsystem sftp /usr/lib/openssh/sftp-server
 </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
-N'oubliez pas de relancer le daemon ssh après avoir modifié ce fichier.
-  service ssh restart
+Voir aussi [[https://man.openbsd.org/sshd_config.5#Subsystem]].
-=== Exemple de fichier /etc/ssh/sshd_config.d/, 2025 ===
+=== Exemple de fichier sshd_config ===
-<WRAP center round todo 60%>
-Je pose ça tant que j'y pense, ceci est la version à jour en 2025 proposé par Tycho. Attention cependant avant de déployer ça sur les serveurs :
-  * Seules les clés Ed25519 seront acceptées
-  * Les protocoles d'échange de clés sont basés sur les travaux post-quantiques, disponibles uniquement à partir d'une certaine version d'OpenSSH (laquelle ?)
-  * Faut "qu'on" documente ici les éléments qui n'ont pas été documenté avant.
-Bref, ne pas utiliser "comme ça", mais ce serait bien de faire évoluer notre fichier d'exemple.
-Et on met dans ''/etc/ssh/sshd_config.d/'' : "le mieux c'est de laisser le ''/etc/ssh/sshd_config'' de base, qui doit inclure tous les fichiers situés dans /etc/ssh/sshd_config.d/." Vérifiez que /etc/ssh/sshd_config inclue bien les fichiers de ''sshd_config.d''.
+Voici à quoi peut ressembler votre fichier ''/etc/ssh/sshd_config.d/myssh''. Adaptez les quelques points à personnaliser.
-</WRAP>
-<code txt /etc/ssh/sshd_config.d/10-hardened.conf>
+<code txt /etc/ssh/sshd_config.d/myssh>
+# Protocole et sécurité de base
+Protocol 2
 StrictModes yes
+# Port 22, si besoin de le changer
+# Chiffrement et algorithmes
 HostKey /etc/ssh/ssh_host_ed25519_key
+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
-KexAlgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,mlkem768x25519-sha256
 PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com
+# Authentification
 PermitRootLogin no
 # AllowUsers zatalyz
@@ Ligne 412: / Ligne 438: @@
 PermitEmptyPasswords no
 KbdInteractiveAuthentication no
+PubkeyAuthentication yes
+UsePAM yes
-MaxAuthTries 2
+# Paramètres de session et de connexion
+MaxAuthTries 6
 LoginGraceTime 30
+ClientAliveInterval 3m
+ClientAliveCountMax 5
+# Comportement à la connexion, environnement
 PrintLastLog yes
+PrintMotd no
 PermitUserEnvironment no
+AcceptEnv LANG LC_*
+# 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>
-==== Gérer les droits des dossiers et autres bonnes pratiques ====
+N'oubliez pas de relancer le daemon ssh après avoir modifié ce fichier.
+  service ssh restart
+====  Autres bonnes pratiques ====
+=== Gérer les droits des dossiers ===
 Si vous ouvrez un accès SSH à plusieurs personnes sur un serveur, cela ne veux pas dire qu'elles ont le droit de tout faire forcément. Ni de tout voir.
@@ Ligne 447: / Ligne 509: @@
 </code>
+=== Tester un fichier ssh ===
+Pour vérifier si votre fichier de configuration va tout faire planter :
+  sudo sshd -t -f /etc/ssh/sshd_config.d/myssh
 ===== Pour aller plus loin =====
   * [[http://doc.fedora-fr.org/wiki/SSH_:_Authentification_par_cl%C3%A9|Une explication plus complète sur les clés ssh, en français.]]
-  * [[http://www.linux-france.org/prj/edu/archinet/systeme/ch13s03.html|Explication sur la configuration de SSH, très claire, complète et en français.]]
   * [[https://man.openbsd.org/sshd_config.5|Toutes les possibilités de sshd_config]], doc officielle en anglais.
 {{tag>Serveur Sysadmin Sécurité}}