Différences

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

--- pratique:informatique:bastionssh [07/05/2025 16:00] – Zatalyz
+++ pratique:informatique:bastionssh [09/05/2025 17:14] (Version actuelle) – [Configuration côté utilisatrice] Zatalyz
@@ Ligne 21: / Ligne 21: @@
 Le Bastion 1 est un serveur en ligne des plus classique. Ce sera le seul point d'accès pour les divers Bastions 2. Les bastions 2, eux, sont en réalité sur les hyperviseurs et donnent accès au réseau local. Cela demande par contre que les Bastion 2 soient vu comme des composants critiques ; une élevation de privilège "là" pourrait avoir de sacrés conséquences.
+==== Conventions ====
-==== Configuration côté utilisatrice ====
-Combien de clés ssh différentes faut-il générer ?
-  * Une clé par serveur cible
-  * Une clé pour accéder à la maintenance des bastions (pour les personnes autorisées bien sûr).
-On différencie bien l'usage du bastion (qui sert juste à "rebondir" jusqu'au serveur final), et l'administration de ces derniers (méga critique : qui a accès au bastion en tant qu'admin peut ensuite y faire plein de choses).
-On peut ensuite avoir des clés différentes pour chaque serveur cible, par contre cela demande d'adapter sa façon de travailler. Personnellement je préfère utiliser une clé pour un ensemble de serveur de la même galaxie.
-En dehors des clés, le seul truc réellement à bidouiller est le fichier "~/.ssh/config" qui simplifiera l'administration. On continuera ensuite de faire "ssh serveur_final" pour aller sur ce dernier, et toute la magie opérera en coulisse.
-<code bash ~/.ssh/config></code>
-=== Conventions ===
 Dans l'exemple, nous aurons
@@ Ligne 42: / Ligne 29: @@
   * "202.1.1.2" est l'adresse du Bastion2 (et oui, je devrais sans doute aussi faire ça en ipv6).
   * 10.0.0.10, 10.0.0.11 et 10.0.0.12 sont des serveurs derrière le Bastion2 et sur un réseau local.
@@ Ligne 77: / Ligne 63: @@
 Concernant le port ssh, dans le cas que je traite, Bastion2 est derrière une box. Cette dernière n'accepte les connexions ssh que sur un port exotique (par exemple le port 2242) mais redirige ensuite en local sur le port 22 de la machine du bastion. Donc pas besoin de modifier le port sur cette dernière. C'est aussi possible de le faire directement avec le pare-feu sur une machine exposée sur internet, mais plus pénible, dans ce cas autant directement utiliser un autre port pour ssh sur la machine.
-<code bash sshd_config/bastion>
+<code bash /etc/ssh/sshd_config.d/bastion>
 # Protocole et sécurité de base
 Protocol 2
@@ Ligne 92: / Ligne 78: @@
 # Authentification
 PermitRootLogin no
-AllowGroups wheel,jump
+AllowGroups wheel jump
 PasswordAuthentication no
@@ Ligne 123: / Ligne 109: @@
 LogLevel VERBOSE
-# Match optionnel pour restreindre plus finement (exemple)
+# Match précise qui a droit à quoi
 Match Group jump
+     # AllowTcpForwarding nécessaire pour que ce soit transmis,
+     # Renseigner ensuite les adresses et ports.
+     AllowTcpForwarding yes
      PermitOpen 10.0.0.10:22
      PermitOpen 10.0.0.11:22
      PermitOpen 10.0.0.12:22
-Match User alice
+Match Group wheel
-     AllowTcpForwarding yes
-Match User lapin
     PermitTTY yes
     ForceCommand none
@@ Ligne 175: / Ligne 161: @@
 </code>
+=== Créer les utilisatrices ===
+Il faut permettre à Alice de passer en rebondissant et sans s'arrêter, et à Lapin de creuser son trou.
+Tout en root/sudo :
+<code>
+groupadd wheel
+groupadd jump
+useradd alice -m -G jump
+mkdir /home/alice/.ssh
+nano /home/alice/.ssh/authorized_keys
+# Mettre la clé publique dans ce fichier
+chown -R alice: /home/alice/.ssh
+chmod 0700 /home/alice/.ssh/
+chmod 0600 /home/alice/.ssh/authorized_keys
+useradd lapin -m -G sudo,wheel  -s /bin/bash
+passwd lapin
+mkdir /home/lapin/.ssh
+nano /home/lapin/.ssh/authorized_keys
+# Mettre la clé publique dans ce fichier
+chown -R lapin: /home/lapin/.ssh
+chmod 0700 /home/lapin/.ssh/
+chmod 0600 /home/lapin/.ssh/authorized_keys</code>
+=== L'hyperviseur a-t-il les bonnes adresses ? ===
+Bastion2 étant l'hyperviseur, il peut avoir sa façon (unique) de gérer les adresses, suivant le pont etc. Pour vérifier si la VM "192.168.1.10" est réellement joignable sous ce nom :
+<code>ip route get 192.168.1.10
+ping 192.168.1.10
+ip neigh</code>
+Si ça ne trace pas la route, si ça ne ping pas... la dernière commande liste les ip voisines, ça peut donner des pistes.
 ==== Configuration côté Serveur final ====
   * sshd_config
   * Accepter uniquement des connexions depuis Bastion2
 <code bash sshd_config/perso>
+# Protocole et sécurité de base
 Protocol 2
-Ciphers aes256-ctr,aes192-ctr,aes128-ctr
+StrictModes yes
-MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
+# Chiffrement et algorithmes
+HostKey /etc/ssh/ssh_host_ed25519_key
+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
+PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com
+# Authentification
 PermitRootLogin no
-StrictModes yes
+AllowGroups wheel
 PasswordAuthentication no
+PermitEmptyPasswords no
 KbdInteractiveAuthentication no
 PubkeyAuthentication yes
 UsePAM yes
-PermitEmptyPasswords no
+# Paramètres de session et de connexion
 MaxAuthTries 6
 LoginGraceTime 30
+ClientAliveInterval 3m
+ClientAliveCountMax 5
-AllowGroups wheel
+# Comportement à la connexion, environnement
-AllowTcpForwarding no
-X11Forwarding no
 PrintLastLog yes
 PrintMotd no
+PermitUserEnvironment no
 AcceptEnv LANG LC_*
-Subsystem sftp /usr/lib/openssh/sftp-server
+# Redirections et accès à distance
+AllowTcpForwarding no
+X11Forwarding no
 </code>
-==== Cas particulier d'un tunnel ====
+=== Cas particulier d'un tunnel ===
 Dans un cas particulier, j'ai hélas besoin de pouvoir parfois utiliser un [[pratique:informatique:box_fai|tunnel]] (fichue box qui ne se gère pas direct en ssh). On peut ajouter ceci depuis le serveur qui va permettre le tunnel :
@@ Ligne 226: / Ligne 251: @@
     AllowTcpForwarding yes
 </code>
+==== Configuration côté utilisatrice ====
+Combien de clés ssh différentes faut-il générer ?
+  * Une clé par serveur cible
+  * Une clé pour accéder à la maintenance des bastions (pour les personnes autorisées bien sûr).
+On différencie bien l'usage du bastion (qui sert juste à "rebondir" jusqu'au serveur final), et l'administration de ces derniers (méga critique : qui a accès au bastion en tant qu'admin peut ensuite y faire plein de choses).
+On peut ensuite avoir des clés différentes pour chaque serveur cible, par contre cela demande d'adapter sa façon de travailler. Personnellement je préfère utiliser une clé pour un ensemble de serveur de la même galaxie.
+En dehors des clés, le seul truc réellement à bidouiller est le fichier "~/.ssh/config" qui simplifiera l'administration. On continuera ensuite de faire "ssh serveur_final" pour aller sur ce dernier, et toute la magie opérera en coulisse.
+Génération des clés :
+<code>ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_alice -C "alice"
+ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_lapin -C "lapin"</code>
+  * -t : type, donc ed25519.
+  * -f : précise le nom du fichier ; permet de retrouver plus facilement ce qui sert "où"
+  * -C : ajoute un commentaire ; sans rien préciser ce sera votre utilisateur@host du système où vous êtes.
+Copier les clés sur les bastions dans "~/.ssh/authorized_keys" (chacun son home).
+<code bash ~/.ssh/config></code>
+=== La partie Alice (au pays des serveurs) ===
+Alice n'a accès (au final) qu'aux VM ; mais elle doit passer par les deux bastions pour ça.
+Génération de sa clé :
+<code>ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_alice -C "alice"</code>
+Copier la clé **publique** sur la/les VM auxquelles elle a accès ainsi que dans les deux bastions, dans ''/home/alice/.ssh/authorized_keys''.
+Son fichier de config avec un seul bastion (tout en local, donc adresse locale !!!). Ça, ça marche.
+<code bash ~/.ssh/config>
+# Bastion2
+Host bastion2
+    HostName 192.168.1.22
+    User alice
+    IdentityFile ~/.ssh/id_ed25519_alice
+    ForwardAgent no
+# Accès à la VM finale (via les deux bastions)
+Host vm-finale
+    HostName 192.168.1.11
+    User alice
+    IdentityFile ~/.ssh/id_ed25519_alice
+    ProxyJump bastion2
+</code>
+<WRAP center round todo 60%>
+<code bash ~/.ssh/config>
+# Bastion1 - 1er saut
+Host bastion1
+    HostName 101.1.1.1
+    User alice
+    IdentityFile ~/.ssh/id_ed25519_alice
+    ForwardAgent no
+# Bastion2 - 2e saut
+Host bastion2
+    HostName 192.168.1.2
+    User alice
+    IdentityFile ~/.ssh/id_ed25519_alice
+    ProxyJump bastion1
+    ForwardAgent no
+# Accès à la VM finale (via les deux bastions)
+Host vm-finale
+    HostName 192.168.1.11
+    User alice
+    IdentityFile ~/.ssh/id_ed25519_alice
+    ProxyJump bastion2
+</code>
+</WRAP>
+Pour se connecter :
+  ssh vm-finale
+<WRAP center round tip 100%>
+Attention si on utilise un script (genre [[pratique:informatique:ansible|Ansible]] pour créer les utilisatrices. Une utilisatrice admin sur la VM ne doit PAS être admin sur le bastion.
+</WRAP>
 {{tag>Informatique, SSH}}