Différences

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

--- fr:ssh [2018/04/26 13:54] – [Paramétrer sshd_config] /* ortho + précisions de version */ merlin8282
+++ fr:ssh [2023/08/14 11:31] (Version actuelle) – [Exemple de fichier sshd_config] zatalyz
@@ Ligne 14: / Ligne 14: @@
 ==== Générer une clé ====
 Ouvrez une console et générez une paire de clefs :
-  ssh-keygen -t rsa -b 4096
+  ssh-keygen -t ed25519
 Ou
-  ssh-keygen -t ecdsa -b 521
+  ssh-keygen -o -t rsa -b 4096
 Vous devriez avoir le texte suivant qui s'affiche :
-<code>Generating public/private rsa key pair.
+<code>Generating public/private ed25519 key pair.
-Enter file in which to save the key (/home/user/.ssh/id_rsa):
+Enter file in which to save the key (/home/user/.ssh/id_ed25519):
 Enter passphrase (empty for no passphrase):
 Enter same passphrase again:
-Your identification has been saved in /home/user/.ssh/id_rsa.
+Your identification has been saved in /home/user/.ssh/id_ed25519.
-Your public key has been saved in /home/user/.ssh/id_rsa.pub.</code>
+Your public key has been saved in /home/user/.ssh/id_ed25519.pub.
+The key fingerprint is:
+SHA256:Gm8P/ecLCNXPKPUEMZO7LV8vNjTjTfdZ8K2DPx7NPws user@hostname
+The key's randomart image is:
++--[ED25519 256]--+
+|            =o   |
+|           ..+   |
+|          . o..  |
+|         . ..*.  |
+|      . S . .o+o.|
+|       + o oo =oB|
+|      . + o .E.BO|
+|       . o ...%+=|
+|          . .*=B+|
++----[SHA256]-----+</code>
 Si vous n'entrez rien pour le fichier où sauver la clef (donc tapez sur "entrée"), cela laissera dans le répertoire par défaut, c'est à dire ''/home/user/.ssh/id_rsa'', ce qui est très bien.
-Pour la "passphrase", trouvez [[fr:consignes_securite#mots_de_passe|un mot de passe efficace]].
+Pour la "passphrase", trouvez [[fr:consignes_securite_people#mots_de_passe|un mot de passe efficace]].
-Une clef publique/privée est générée, spécifiquement pour les connexions ssh, en utilisant l’algorithme RSA dans la première commande ou ECDSA dans la seconde.
+Une clef publique/privée est générée, spécifiquement pour les connexions ssh, en utilisant l’algorithme Ed25519 dans la première commande ou RSA dans la seconde.
-L'ajout du paramètre ''-b (chiffre)'' permet de fixer la taille de la clé, augmentant sa sécurité.
+L'ajout du paramètre ''-b (chiffre)'' permet de fixer la taille de la clé, augmentant sa sécurité. Ed25519 utilisant une taille fixe, le paramètre ''-b'' n'est pas applicable dans ce cas.
+L'ajout du paramètre ''-o'' permet d'utiliser le nouveau mode de chiffrement de la clé, contrairement à celui par défaut qui [[https://latacora.singles/2018/08/03/the-default-openssh.html|n'est plus considéré comme sûr]]. Ed25519 utilisant ce nouveau mode par défaut, il est inutile de le préciser. Si vous aviez préalablement généré des clés RSA, DSA ou ECDSA sans préciser le paramètre ''-o'', vous pouvez les convertir en changeant le mot de passe avec la commande suivante :
+  ssh-keygen -p -o -f chemin/vers/la/clé/privée
+=== RSA, ECDSA ou Ed25519 ? ===
+Il existe différents protocoles pour générer une clé, en suivant la syntaxe ''ssh-keygen -t type'', ''type'' étant à remplacer par ''dsa'', ''rsa'', ''ecdsa'' ou ''ed25519''.
+  * DSA n'est plus accepté partout car considéré comme insuffisamment sûr.
+  * RSA est la référence par défaut, acceptée sur tous les serveurs. Cependant, afin de rester sûr il est nécessaire de générer des clés très grandes et sa conception fait que nous atteignons actuellement une limite de taille, [[https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096|des clés plus grandes n'ajoutant pas significativement plus de sécurité]].
+  * ECDSA est une variante de DSA qui, contrairement à ce dernier, repose sur l'utilisation des [[https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques|courbes elliptiques]]. À niveau de sécurité égal avec RSA, ECDSA utilise des clés d'une taille bien plus petite et est bien plus rapide.
+  * Ed25519, aussi appelé EDDSA, est, tout comme ECDSA, une variante de DSA utilisant les courbes elliptiques. La différence avec ECDSA est l'utilisation de la courbe [[https://fr.wikipedia.org/wiki/Curve25519|Curve25519]] qui offre certains avantages supplémentaires, en particulier une plus grande rapidité. Étant plus récente, elle n'est pas encore supportée partout.
+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).
-=== RSA ou ECDSA ? ===
-Il existe différents protocoles pour générer une clé, en suivant la syntaxe ''ssh-keygen -t type'', ''type'' étant à remplacer par ''dsa'', ''rsa'', ''ecdsa''.
-  * DSA n'est plus accepté partout, c'est vraiment ancien.
-  * ECDSA est théoriquement accepté partout à présent et son empreinte est moins longue, donc plus rapide à contrôler, c'est le dernier arrivé.
-  * Enfin, RSA est la référence, acceptée sur tous les serveurs.
-Y'a-t-il vraiment un avantage entre RSA et ECDSA ? Les débats sont nombreux. Ce qui en ressort, c'est que  dans la majorité des cas... l'un ou l'autre peuvent être utilisé indifférement.
 ==== Le fichier /home/user/.ssh/config ====
 Ce fichier permet de personnaliser ses accès à ssh de façon extrêmement pratique.
@@ Ligne 91: / Ligne 101: @@
 <WRAP center round tip 90%>
-Cela n'a généralement aucun intérêt : la même clé peut vous permettre de vous connectez sur tous les serveurs que vous souhaitez. Les clés asymétriques ne sont pas comme les mots de passe ; la sécurité n'augmente pas en utilisant une différente à chaque endroit, d'autant que ce qui est envoyé est la clé //publique// qui par définition peut être publique sans rien comprommettre.
+Cela n'a généralement aucun intérêt : la même clé peut vous permettre de vous connectez sur tous les serveurs que vous souhaitez. Les clés asymétriques ne sont pas comme les mots de passe ; la sécurité n'augmente pas en utilisant une différente à chaque endroit, d'autant que ce qui est envoyé est la clé //publique// qui par définition peut être publique sans rien compromettre.
 Cependant, c'est parfois une manipulation nécessaire. Par exemple, il fut un temps où Bitbucket ne supportait pas ECDSA, il fallait donc une clé RSA pour ce service et quelques autres serveurs en retard.
@@ Ligne 97: / Ligne 107: @@
-Imaginons qu'on ait généré deux clefs RSA comme indiqué au-dessus. Il suffit d'indiquer pour cela un autre nom à la question "Enter file in which to save the key (/home/user/.ssh/id_rsa)" : ''/home/user/.ssh/cle1'' et ''/home/user/.ssh/cle2''. On a donc décidé d'utiliser les clefs comme suit:
+Imaginons qu'on ait généré deux clefs RSA comme indiqué au-dessus. Il suffit d'indiquer pour cela un autre nom à la question "Enter file in which to save the key (/home/user/.ssh/id_rsa)" : ''/home/user/.ssh/cle1'' et ''/home/user/.ssh/cle2''. On a donc décidé d'utiliser les clefs privées comme suit:
-  * cle1  pour aller sur le serveur 1
+  * clepriv1 pour aller sur le serveur 1
-  * cle2 pour aller sur le serveur 2
+  * clepriv2 pour aller sur le serveur 2
 <code txt config>
 host serveur1
 	HostName serveur1.fr
-	IdentityFile ~/.ssh/cle1
+	IdentityFile ~/.ssh/clepriv1
 	User totor
 host serveur2
 	HostName 202.127.12.13
-	IdentityFile ~/.ssh/cle2
+	IdentityFile ~/.ssh/clepriv2
 	User roxxor
 </code>
-Ensuite quand on se connectera avec SSH, le système saura que pour aller sur serveur1.fr, il faut qu'il utilise la clef ~/.ssh/cle1 et l'identifiant totor. Il ne restera qu'à entrer la passphrase qui y est liée. Il n'y a plus besoin de donner la clef nécessaire ou l'identifiant.
+Ensuite quand on se connectera avec SSH, le système saura que pour aller sur serveur1.fr, il faut qu'il utilise la clef ~/.ssh/clepriv1 et l'identifiant totor. Il ne restera qu'à entrer la passphrase qui y est liée. Il n'y a plus besoin de donner la clef nécessaire ou l'identifiant.
 ===== Se connecter à un serveur avec sa clé =====
@@ Ligne 177: / Ligne 187: @@
 ===== Configurer SSH sur ses serveurs =====
-<WRAP center round todo 60%>
-En brouillon.
-</WRAP>
 La connexion par mot de passe doit être désactivée partout. La seule façon de se connecter est d'utiliser une clé SSH.
@@ Ligne 240: / Ligne 246: @@
 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 sandbox # si dispo sinon
   # UsePrivilegeSeparation yes
-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>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
@@ Ligne 257: / Ligne 265: @@
 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.
-  ChallengeResponseAuthentication no
+  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]].
+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
@@ Ligne 274: / Ligne 282: @@
   UsePAM yes
-En complément de ''PasswordAuthentication no'' et ''ChallengeResponseAuthentication no'' ; l'option est nécessaire pour que les utilisateurs UNIX puissent s'identifier.
+En complément de ''PasswordAuthentication no'' et ''KbdInteractiveAuthentication no'' ; l'option est nécessaire pour que les utilisateurs UNIX puissent s'identifier.
@@ Ligne 283: / Ligne 291: @@
 MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-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, voir http://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf page 11.
+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
@@ Ligne 323: / Ligne 331: @@
 PermitRootLogin no
 StrictModes yes
-UsePrivilegeSeparation sandbox # si dispo sinon
-# UsePrivilegeSeparation yes
 PasswordAuthentication no
-ChallengeResponseAuthentication no
+KbdInteractiveAuthentication no
 PubkeyAuthentication yes
 UsePAM yes
@@ Ligne 359: / Ligne 365: @@
   * [[https://man.openbsd.org/sshd_config.5|Toutes les possibilités de sshd_config]], doc officielle en anglais.
-{{tag>Serveur Administration Sécurité Obsolète}}
+{{tag>Serveur Sysadmin Sécurité}}