Différences

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

--- fr:ssh [2018/10/07 12:53] – [RSA ou ECDSA ?] Refonte partielle en incluant Ed25519 Tycho Brahe
+++ fr:ssh [2025/01/29 21:24] (Version actuelle) – [RSA, ECDSA ou Ed25519 ?] zatalyz
@@ Ligne 41: / Ligne 41: @@
 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]].
@@ 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 107: / Ligne 109: @@
-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 187: / Ligne 189: @@
 ===== 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 250: / Ligne 248: @@
 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 267: / Ligne 267: @@
 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 284: / Ligne 284: @@
   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 333: / Ligne 333: @@
 PermitRootLogin no
 StrictModes yes
-UsePrivilegeSeparation sandbox # si dispo sinon
-# UsePrivilegeSeparation yes
 PasswordAuthentication no
-ChallengeResponseAuthentication no
+KbdInteractiveAuthentication no
 PubkeyAuthentication yes
 UsePAM yes
@@ Ligne 363: / Ligne 361: @@
   service ssh restart
+=== Exemple de fichier /etc/ssh/sshd_config.d/, 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.
+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''.
+</WRAP>
+<code txt /etc/ssh/sshd_config.d/10-hardened.conf>
+StrictModes yes
+HostKey /etc/ssh/ssh_host_ed25519_key
+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
+PermitRootLogin no
+# AllowUsers zatalyz
+# OU
+AllowGroups wheel
+PasswordAuthentication no
+PermitEmptyPasswords no
+KbdInteractiveAuthentication no
+MaxAuthTries 2
+LoginGraceTime 30
+PrintLastLog yes
+PermitUserEnvironment no
+AllowTcpForwarding no
+X11Forwarding no
+</code>
+==== Gérer les droits des dossiers et autres bonnes pratiques ====
+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.
+<WRAP center round info 90%>
+Rappel vite fait pour créer une utilisatrice avec son groupe associé, un home et un shell fonctionnel (remplacer ''USER'') :
+  sudo useradd USER -m -U -s /bin/bash
+Et penser à lui mettre un mot de passe :
+  sudo passwd USER
+</WRAP>
+Debian crée par défaut des répertoires "home" avec droit de lecture pour tout le monde (other). Enlever ces droits permet déjà d'isoler un peu :
+  sudo chmod o-rx /home/*
+Ça n'empêchera pas quelqu'un qui peut passer en root de tout voir au besoin.
+Si l'objectif est d'ouvrir un accès web, il me semble plus facile de gérer en créant un dossier "web" dans le dossier de l'utilisatrice, puis faire un lien symbolique depuis /var/www, et donner les droits à www-data d'agir dessus :
+<code>
+sudo mkdir /home/USER/web
+sudo chmod ln -s /home/USER/web /var/www/SITE_USER/
+sudo chown -R USER:www-data  /home/USER/web
+</code>
 ===== 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.]]
@@ Ligne 369: / Ligne 431: @@
   * [[https://man.openbsd.org/sshd_config.5|Toutes les possibilités de sshd_config]], doc officielle en anglais.
-{{tag>Serveur Sysadmin Sécurité Obsolète}}
+{{tag>Serveur Sysadmin Sécurité}}