Différences

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

--- doc:formations:hebergement:serveur:ssh [2022/07/27 10:22] – [Tunnels SSH inverse] jeremie
+++ doc:formations:hebergement:serveur:ssh [2024/01/29 15:56] (Version actuelle) – [Tunnels SSH inverse] jeremie
@@ Ligne 126: / Ligne 126: @@
   RequestTTY no
 </code>
+Autoriser un "forward X11" permet d'exporter un affichage graphique vers un client SSH, à la condition que le serveur source dispose d'un serveur X. Faites un ''export DISPLAY=$(echo $SSH_CLIENT|cut -f1 -d\ ):0.0'' côté serveur, après avoir fait un ''xhost +'' coté client. Il est cependant probablement plus facile et efficace d'utiliser [[doc:formations:hebergement:serveur:vnc|TigerVNC]].
 ==== Restreindre les commandes appelables ====
@@ Ligne 155: / Ligne 157: @@
 === Tunnels SSH inverse ===
-On peut aussi créer des tunnels SSH inverses. Leur rôle est d'ouvrir sur le serveur distant un tunnel qui "redescend" vers le poste qui a ouvert le tunnel, ce qui permet d'ignorer les contraintes du réseau local, tant qu'il permet d'utiliser SSH. On n'a pas à se soucier de NAT ou de reconfiguration du gateway ou de la DMZ.
+On peut aussi créer des tunnels SSH inverses. Leur rôle est d'ouvrir sur le serveur distant un tunnel qui "redescend" vers le poste qui a ouvert le tunnel, ce qui permet d'ignorer les contraintes du réseau local, tant qu'il permet d'utiliser SSH. On n'a pas à se soucier d'adresses, de NAT ou de reconfiguration du gateway ou de la DMZ.
-Pour se faire on crée un compte SSH bridé à cette seule action, et on le paramètre dans le ''/etc/ssh/sshd_config'' du serveur;
+Pour se faire on crée un compte SSH ''usertssh'' que l'on bride à cette seule action, et on le paramètre dans le ''/etc/ssh/sshd_config'' du serveur;
 <code>
@@ Ligne 166: / Ligne 168: @@
 </code>
-On peut vérifier la contrainte en essayant de se logguer interactivement:
+On peut vérifier la contrainte en essayant de se logguer interactivement depuis son poste (une fois ajouté dans le ''.ssh/authorized_keys'' de ''usertssh''):
   #ssh usertssh@myserver.com
   Ce compte est limité à du tunnel SSH. Connection to myserver.com closed.
-Bridé ou non, sur son poste on peut utiliser ''autossh'' à la place de SSH, car c'est un outil pratique qui relance automatiquement le tunnel s'il tombe:
+On va utiliser ici ''autossh'' à la place de SSH, car c'est un outil pratique qui relance automatiquement le tunnel s'il tombe:
   # depuis le poste client
@@ Ligne 177: / Ligne 179: @@
   autossh -fN -M 3986 -R 65432:localhost:22 usertssh@myserver.com
-Cela ouvrira sur le serveur un accès "local" SSH sur le port 65432. Quand on est loggué sur le serveur on peut l'utiliser pour redescendre vers la machine qui a ouvert ce tunnel, tout simplement. Si l'on est loggué sur le serveur et qu'on a sa clé publique dans le ''.ssh/authorized_hosts'' de l'utilisateur sur le poste qui a ouvert le tunnel sur le serveur:
+Cela ouvrira sur le serveur un accès "local" SSH sur le port 65432. Quand on est loggué sur le serveur on peut l'utiliser pour redescendre vers la machine qui a ouvert ce tunnel, tout simplement (et on ressortira ici sur le port 22).
+Loggué sur le serveur et avec sa clé publique dans le ''.ssh/authorized_hosts'' de l'utilisateur sur le poste qui a ouvert le tunnel sur le serveur:
   # depuis le serveur
@@ Ligne 249: / Ligne 253: @@
   * mais rien n'empeche de faire ''ssh toto@service.valorhiz.com''. Puisque l'on spécifie explicitement l'utilisateur, il se sera pas écrasé avec ''User jeremie'', et n'utilisera que les autres définitions par défaut.
+====== Partage de session SSH ======
+[[https://github.com/elisescu/tty-share|tty-share]] est un outil sympa qui permet de partager un shell avec d'autres (au sens de co-rédacteur!), y compris via un navigateur web.
+La version la moins invasive tourne dans un docker ainsi:
+  docker run -it elisescu/tty-share --public
+:!: Attention aux problèmes évidents de sécurité, mais c'est un bel outil pour demander de l'aide !
 ====== Restriction d'usage d'un compte SSH ======