Différences

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

--- pratique:informatique:bastionssh [07/05/2025 18:02] – Zatalyz
+++ pratique:informatique:bastionssh [09/05/2025 17:14] (Version actuelle) – [Configuration côté utilisatrice] Zatalyz
@@ Ligne 63: / 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 78: / Ligne 78: @@
 # Authentification
 PermitRootLogin no
-AllowGroups wheel,jump
+AllowGroups wheel jump
 PasswordAuthentication no
@@ Ligne 109: / 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 161: / 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 ===
 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 241: / Ligne 280: @@
 Génération de sa clé :
 <code>ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_alice -C "alice"</code>
-<WRAP center round todo 60%>
-Copier la clé sur la/les VM auxquelles elle a accès ainsi que dans les deux bastions, dans ''/home/alice/.ssh/authorized_keys''.
+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
+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
@@ Ligne 275: / Ligne 330: @@
 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}}