Différences

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

--- fr:ssh [2025/01/29 21:19] – [Exemple de fichier sshd_config] 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 59: / Ligne 59: @@
 Actuellement (octobre 2018) les seules clés considérées comme fiables sont les clés Ed25519, ECDSA ou RSA d'une taille au moins égale à 2048 bits (4096 ou plus étant mieux mais pas significativement).
+Sur les serveurs de Khaganat, nous n'acceptons que les clés Ed25519.
 ==== Le fichier /home/user/.ssh/config ====
 Ce fichier permet de personnaliser ses accès à ssh de façon extrêmement pratique.
@@ Ligne 156: / Ligne 158: @@
   eval "$(ssh-agent -s)"
-  ssh-add ~/.ssh/id_rsa
+  ssh-add -t 1h ~/.ssh/id_ed25519
 Vous devrez retaper cette commande à chaque redémarrage de votre session, avant de vous connecter en ssh pour la première fois lors de la session.
@@ Ligne 162: / Ligne 164: @@
 Pour vous simplifier la vie, vous pouvez créer un petit alias (dans /home/user/.aliases si vous utilisez bashrc et que vous avez bien activé cette option) :
-  alias mykey='eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_rsa'
+  alias mykey='eval "$(ssh-agent -s)" && ssh-add -t 1h ~/.ssh/id_ed25519'
 Il n'y aura plus qu'à taper ''mykey'' dans votre console lors de votre première connexion ssh de la journée et ce sera déverouillé pour la session.
+Concernant ssh-agent, quelques infos utiles :
+  * ''-t 1h'' déclare que la déclaration est valable 1h. On peut adapter plus long, mais c'est bien de ne pas laisser ouvert sans limite. Accessoirement fermer la session shell suffira à annuler la session lié à ssh-agent. Sans donner d'indication, le temp est en seconde (''-t 3600'' = 1h = 60m). Il y a aussi ''d'' pour //days// (jours) et w pour //weeks// (semaines), mais qui déclarerait si long ? Les unités de temps (s/m/h/d/w) peuvent aussi être en majuscules, ça se vaut (S/M/H/D/W). Par défaut, sans rien préciser, c'est "forever" (enfin jusqu'à ce que la session se termine...). Et on peut très bien écrire ''-t 1h30m40s'' si on aime se complique les choses.
+  * ''ssh-add -l'' liste les clés actuellement renseignés, si on a un doute.
+  * ''ssh-add -D'' les vide (sans avoir besoin de fermer la session).
+  * On peut ajouter plusieurs clés en une fois, avec une commande du type ''ssh-add ~/.ssh/id_ed25519 ~/.ssh/id_ed25519_bis ~/.ssh/id_ed25519_ter''.
+Le [[https://linux.die.net/man/1/ssh-agent|manuel]] liste quelques autres options.
 ==== Se connecter sans mot de passe (méthode non sécurisée) ====
 <WRAP center round important 60%>
@@ Ligne 219: / Ligne 228: @@
 Ssh doit donc être configuré pour être bien sécurisé et ne pas permettre qu'un attaquant se connecte par ce biais.
-<WRAP center round important 60%>
+<WRAP center round important 90%>
-Cette partie a été mise à jour le 6 février 2018. La sécurité étant un domaine en perpétuelle évolution, tenez-vous au courant, n'appliquez pas bêtement et veillez à utiliser des informations récentes.
+Cette partie a été mise à jour le 7 mai 2025. La sécurité étant un domaine en perpétuelle évolution, tenez-vous au courant, n'appliquez pas bêtement et veillez à utiliser des informations récentes.
 </WRAP>
@@ Ligne 227: / Ligne 236: @@
 </WRAP>
-La configuration de base sur Debian est relativement correcte ; il y a quelques options qui gagnent à être expliquées et d'autres qui gagnent à être modifiées. Certaines options sont déjà configurées par défaut sur la bonne valeur, même quand elles sont commentées, mais ça va toujours mieux en le disant explicitement.
+La configuration de base sur Debian est relativement correcte ; il y a quelques options qui gagnent à être expliquées et d'autres qui gagnent à être modifiées. Certaines options sont déjà configurées par défaut sur la bonne valeur, même quand elles sont commentées, mais ça va toujours mieux en le disant explicitement. <wrap info>Certaines informations précisées sont donc déjà les valeurs par défaut ; en les déclarant, on assume qu'on en maitrisera mieux les détails que les mainteneurs du paquet.</wrap>
-Le fichier à modifier est ''/etc/ssh/sshd_config''.
-  # What ports, IPs and protocols we listen for
+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 ===
+  Protocol 2
+SSh a évolué et nous utilisons à présent la seconde version du protocole. Pour des raisons de compatibilité, le protocole 1 n'est pas désactivé (et n'est utile que si vous n'avez pas mis à jour votre installation, hein), sauf si votre version d'OpenSSH est ≥7.6. En renseignant cette option, vous vous assurez d'utiliser uniquement la dernière version.
   Port 22
-Cette option peut être modifiée pour qu'un attaquant automatique soit bloqué : par contre il faudra préciser le port ssh pour se connecter. La commande ne sera donc plus ''ssh identifiant@serveur.com'' mais ''ssh identifiant@serveur.com -p monport''. Suivant votre installation((Votre serveur est directement relié à internet ? Changez son port pour la connexion SSH. Il est au sein d'un réseau interne, derrière un pare-feu ? C'est pas forcément utile, de toute façon on ne s'y connectera pas depuis l'extérieur grâce au port 22.)), il peut être intéressant de mettre autre chose que 22 (port par défaut, ciblé par pas mal de bots), tout en sachant que changer de port ne suffit pas à protéger votre serveur.
+Cette option peut être modifiée pour qu'un attaquant automatique soit bloqué : par contre il faudra préciser le port ssh pour se connecter. La commande ne sera donc plus ''ssh identifiant@serveur.com'' mais ''ssh identifiant@serveur.com -p monport''. Suivant votre installation((Votre serveur est directement relié à internet ? Changez son port pour la connexion SSH. Il est au sein d'un réseau interne, derrière un pare-feu ? Ce n'est pas forcément utile, de toute façon on ne s'y connectera pas depuis l'extérieur grâce au port 22.)), il peut être intéressant de mettre autre chose que 22 (port par défaut, ciblé par pas mal de bots), tout en sachant que changer de port ne suffit pas à protéger votre serveur.
+  StrictModes yes
+Cela garantit que le serveur vérifie les modes et droits des fichiers de l'utilisateur avant de se connecter.
+=== 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%>
+> 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
+</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
+</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 !
+=== Authentification ===
   PermitRootLogin no
@@ Ligne 241: / Ligne 295: @@
 La première option interdit de se connecter en root directement via ssh. C'est l'option la plus sécurisée. Il faudra donc se connecter en ssh avec un nom d'utilisateur basique, puis passer en root si nécessaire.
-La seconde option permet de se connecter en root **uniquement** si [[fr:ssh#se_connecter_a_un_serveur_avec_sa_cle|la clé ssh a été envoyée au serveur]]. C'est relativement sécurisé, tant que votre propre clé est elle-même en sécurité. Préférez l'utilisation d'un compte utilisateur non-root pour vous connecter !
+La seconde option permet de se connecter en root **uniquement** si [[fr:ssh#se_connecter_a_un_serveur_avec_sa_cle|la clé ssh a été envoyée au serveur]]. C'est relativement sécurisé, tant que votre propre clé est elle-même en sécurité. Mais préférez l'utilisation d'un compte utilisateur non-root pour vous connecter !
-  StrictModes yes
-Cela garantit que le serveur vérifie les modes et droits des fichiers de l'utilisateur avant de se connecter.
-  #UsePrivilegeSeparation sandbox # si dispo sinon
-  # UsePrivilegeSeparation yes
-<del>La première option, si elle est supportée par votre version de SSH, permet de bien séparer les privilèges et est à privilégier. Si vous avez une version SSH un peu plus ancienne ou ≥7.5((Dans OpenSSH en version 3.2.2 ''UsePrivilegeSeparation'' est encore expérimental. Dans la version 3.3 l'option est à ''yes'' par défaut. En version 5.8 l'option autorise le nouveau paramètre ''sandbox''. Enfin, dans OpenSSH 7.5 ''UsePrivilegeSeparation'' est rendu obsolète car de toute manière c'est activé par défaut en mode ''sandbox'')), la seconde reste très acceptable.</del>
-Cette option est dépréciée depuis la 7.5 car la séparation des privilèges est maintenant par défaut (et depuis un moment). Cette option n'a de sens que sur de très vieux serveurs, qui feraient mieux de ne pas être exposés à internet.
   AllowUsers Pseudo1 Moi Toiaussi
+  # OU
   AllowGroups wheel
@@ Ligne 261: / Ligne 307: @@
 À noter que vous pouvez aussi spécifier l'accès à une plage d'ip : ''AllowUsers admin@192.168.14/24'' ; se référer à la doc de SSH pour plus d'infos.
+Par contre, n'essayez pas de mixer : c'est soit "AllowGroups" soit "AllowUsers" ; mettre les deux paramètres (même si votre user est dans wheel) est une bonne façon de ne plus pouvoir se connecter du tout.
   PasswordAuthentication no
 Interdit purement et simplement à tous les utilisateurs de se connecter via ssh avec un mot de passe : il faut forcément une clé ssh enregistrée sur le serveur.
-  KbdInteractiveAuthentication no
-Cela va avec le paramètre précédent et le complète. La meilleure explication (en anglais) est [[https://superuser.com/questions/161609/can-someone-explain-the-passwordauthentication-in-the-etc-ssh-sshd-config-fil/374234#374234|ici]]. Autrefois ''ChallengeResponseAuthentication'', devenu ''KbdInteractiveAuthentication''
   PermitEmptyPasswords no
 Cela interdit de se connecter sans mot de passe. C'est sans doute superflu vu que de toute façon on oblige à se connecter avec sa clé SSH, mais dans le doute, on le renseigne.
-  MaxAuthTries 6
+  KbdInteractiveAuthentication no
-Spécifie le nombre de tentatives d'authentification par connexion. L'ANSSI préconise 2 (6 étant la valeur par défaut) ; personnellement, entre ma capacité à me planter en tapant la passphrase de ma clé SSH et le fait que j'ouvre parfois 3 connexions au même serveur en même temps, j'ai préféré mettre un chiffre un peu plus grand afin de ne pas me faire éjecter de mes propres serveurs, tout en étant assez petit pour limiter une attaque par bruteforce.
+Cela va avec le paramètre précédent et le complète. La meilleure explication (en anglais) est [[https://superuser.com/questions/161609/can-someone-explain-the-passwordauthentication-in-the-etc-ssh-sshd-config-fil/374234#374234|ici]]. Autrefois ''ChallengeResponseAuthentication'', devenu ''KbdInteractiveAuthentication''
-  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é.
   PubkeyAuthentication yes
 Autorisé par défaut, comme toujours c'est aussi bien en le déclarant... Permet simplement d'utiliser les clés SSH pour se connecter au serveur !
   UsePAM yes
 En complément de ''PasswordAuthentication no'' et ''KbdInteractiveAuthentication no'' ; l'option est nécessaire pour que les utilisateurs UNIX puissent s'identifier.
+=== Paramètres de session et de connexion ===
+  MaxAuthTries 6
+Spécifie le nombre de tentatives d'authentification par connexion. L'ANSSI préconise 2 (6 étant la valeur par défaut) ; personnellement, entre ma capacité à me planter en tapant la passphrase de ma clé SSH et le fait que j'ouvre parfois 3 connexions au même serveur en même temps, j'ai préféré mettre un chiffre un peu plus grand afin de ne pas me faire éjecter de mes propres serveurs, tout en étant assez petit pour limiter une attaque par bruteforce.
-  Protocol 2
+  LoginGraceTime 30
-SSh a évolué et nous utilisons à présent la seconde version du protocole. Pour des raisons de compatibilité, le protocole 1 n'est pas désactivé (et n'est utile que si vous n'avez pas mis à jour votre installation, hein), sauf si votre version d'OpenSSH est ≥7.6. En renseignant cette option, vous vous assurez d'utiliser uniquement la dernière version.
+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é.
-<code>Ciphers aes256-ctr,aes192-ctr,aes128-ctr
+  ClientAliveInterval 3m
-MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
+Toutes les 3 minutes, la session ssh enverra un "ping" au client pour vérifier s'il est toujours présent.
-</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, voir http://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf page 11. A contrario on peut [[https://security.stackexchange.com/questions/39756/secure-configuration-of-ciphers-macs-kex-available-in-ssh|lire ici]] que les algorithmes utilisés par OpenSSH peuvent être considérés comme sûrs.
-  AllowTcpForwarding no
+  ClientAliveCountMax 5
-Il est possible, via SSH, de faire des trucs fun avec TCP, mais mal maitrisé, cela peut ouvrir des failles à un attaquant. On ne va pas faire compliqué, sauf besoin spécifique, vous devez désactiver ceci et le mettre à ''no''.
+Après 5 "ping" sans réponse, la session sera fermée. Donc potentiellement au bout de 15 minutes.
-  X11Forwarding no
+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 :
-''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.
+  * 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
 Cette option permet surtout de faire un contrôle "humain" des incohérences. Lors de votre connexion ssh, un message vous indiquera les informations de la dernière connexion, ce qui peut permettre de s'inquiéter si ça ne ressemble pas à ce que vous savez des connexions au serveur...
@@ Ligne 304: / Ligne 349: @@
   PrintMotd no
 Précise si sshd affiche le contenu du fichier /etc/motd quand un utilisateur se connecte en mode interactif et par défaut à "yes". Comme c'est généralement le shell qui gère ça, on peut passer à "no", ce qui permet aux utilisateurs que ça gonfle de tout simplement le désactiver, tout en laissant les autres le garder, le tout sur le même serveur.
+  PermitUserEnvironment no
+Ce paramètre contrôle si l’utilisatrice a le droit de définir des variables d’environnement personnalisées au moment de la connexion SSH. Permettre cela offre la possibilité d'élevations de privilèges. Cela n'empêche pas, par ailleurs, que l'utilisatrice personnalise son environnement via les ''.bashrc'' et ''.profile'' (par exemple.
   AcceptEnv LANG LC_*
-Là, de ce que je comprends, cela permet à l'utilisateur de passer avec ses propres variables d'environnement (pour la langue). Il est //possible// que l'option AcceptEnv [[https://tools.cisco.com/security/center/viewAlert.x?alertId=33381|ouvre une faille]] même si, là, avec ça, je ne suis pas sûre. Comme nous sommes en français avec des accents bizarres, il me semble raisonnable de laisser ça (au risque, sinon, de ne plus pouvoir entrer nos mots de passe). <wrap important>Si vous comprenez exactement les enjeux de cette ligne, merci de le préciser.</wrap>
+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
+=== Redirections et accès à distance ===
-Appelle un daemon pour gérer certains aspects, ici sftp.
+  AllowTcpForwarding no
-<WRAP center round help 90%>
+Il est possible, via SSH, de faire des trucs fun avec TCP, mais mal maitrisé, cela peut ouvrir des failles à un attaquant. On ne va pas faire compliqué, sauf besoin spécifique, vous devez désactiver ceci et le mettre à ''no''.
-Présent dans tous les fichiers sshd_config des diverses distributions Linux que j'ai pu voir, je préfère le laisser "dans le doute", car sftp est bien pratique. Cependant, sftp mal configuré peut ouvrir aussi des failles, donc, si vous en savez plus, n'hésitez pas à partager votre savoir.
-</WRAP>
+  X11Forwarding no
+''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.
-=== Exemple de fichier sshd_config ===
+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
-Voici à quoi peut ressembler votre fichier ''/etc/ssh/sshd_config''. Adaptez les quelques points à personnaliser.
+Match Group wheel
+    ChrootDirectory none
-<code txt ssh_config>
+    ForceCommand none
-#Port 22
+    PermitTTY yes
-Protocol 2
+    PermitUserRC yes
-Ciphers aes256-ctr,aes192-ctr,aes128-ctr
-MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
+Match Group sftpusers
+    ChrootDirectory /home/%u
-PermitRootLogin no
+    ForceCommand internal-sftp -d /sftp
-StrictModes yes
+    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.
-PasswordAuthentication no
+À 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".
-KbdInteractiveAuthentication no
-PubkeyAuthentication yes
-UsePAM yes
-PermitEmptyPasswords no
+Un autre point important : ajoutez sftpusers à la directive ''AllowGroups'' sinon... ça ne marchera pas.
-MaxAuthTries 6
+  AllowGroups wheel sftpusers
-LoginGraceTime 30
-AllowGroups wheel
-AllowTcpForwarding no
+Voir aussi [[https://man.openbsd.org/sshd_config.5#Subsystem]].
-X11Forwarding no
-PrintLastLog yes
+=== Exemple de fichier sshd_config ===
-PrintMotd no
-AcceptEnv LANG LC_*
-Subsystem sftp /usr/lib/openssh/sftp-server
+Voici à quoi peut ressembler votre fichier ''/etc/ssh/sshd_config.d/myssh''. Adaptez les quelques points à personnaliser.
-</code>
+<code txt /etc/ssh/sshd_config.d/myssh>
+# Protocole et sécurité de base
-N'oubliez pas de relancer le daemon ssh après avoir modifié ce fichier.
+Protocol 2
-  service ssh restart
-=== Exemple de fichier sshd_config, 2025 ===
-<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.
-</WRAP>
-<code txt ssh_config>
 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 387: / 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 422: / 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é}}