Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
doc:formations:hebergement:serveur:ssh [2022/07/27 10:13] – [Restreindre aux tunnels ssh] jeremie | doc:formations:hebergement:serveur:ssh [2024/01/29 15:56] (Version actuelle) – [Tunnels SSH inverse] jeremie |
---|
RequestTTY no | RequestTTY no |
</code> | </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 ==== | ==== Restreindre les commandes appelables ==== |
==== Restreindre aux tunnels ssh ==== | ==== Restreindre aux tunnels ssh ==== |
| |
Un tunnel SSH permet de créer localement un service d'écoute sur un port, qui redirige la communication vers un serveur distant et un autre port, tout en la cryptant. C'est quelque part une forme très légère et réduite de VPN pour un service spécifique. | === Généralité sur les tunnels === |
| |
| Un tunnel SSH permet de créer localement un service d'écoute sur un port, qui redirige la communication vers un serveur distant et un autre port, tout en la cryptant. C'est quelque part une forme très légère et réduite de [[doc:formations:hebergement:service:wireguard|VPN]] pour un service spécifique: |
| |
| Par exemple si l'on veut ouvrir localement un service distant VNC (bureau virtuel à distance), on exécute localement cette commande: |
| |
| ssh vnc@tiger.server.com -L 5901:127.0.0.1:5901 |
| |
| === 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 d'adresses, de NAT ou de reconfiguration du gateway ou de la DMZ. |
| |
| 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> | <code> |
</code> | </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 | #ssh usertssh@myserver.com |
Ce compte est limité à du tunnel SSH. Connection to myserver.com closed. | Ce compte est limité à du tunnel SSH. Connection to myserver.com closed. |
| |
Ensuite sur son PC (''autossh'' est un outil pratique pour relancer la connexion si elle se ferme): | 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 | # depuis le poste client |
autossh -fN -M 3986 -R 65432:localhost:22 usertssh@myserver.com | 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 | # depuis le serveur |
* 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. | * 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 ====== | ====== Restriction d'usage d'un compte SSH ====== |