Ce billet est un petit peu l’inverse de l’avant-dernier..

La technique décrite ici permet à plusieurs utilisateurs distants connectés sur la même machine d’interagir dans le même terminal..

Ceci peut se révèler très pratique par exemple pour montrer à l’administrateur de la machine sur laquelle vous êtes connectés (tous les 2), les commandes et tout ce que vous tapez sur son serveur… (Méthode différente qu’en utilisant la commande script)

Exemple simpliste en démo:

screen-x–8avril2006

L’utilisation générale de screen: http://gentoo-wiki.com/TIP_Using_screen
L’utilisation de screen en multiuser:
http://gentoo-wiki.com/HOWTO_Snoop_terminal_session#Screen

Je récupère aujourd’hui un pointer laser faisant également télécommande Bluetooth pour faire “slide suivant/précédent” dans les présentations…

La boiboite n’indique biensûr que Windows/Mac.

Je branche la clé Usb Bluetooth sous Ubuntu…et ohhhh…

input: USB HID v1.10 Keyboard [ALCOR USB Multimedia Keyboard] on usb-0000:00:1d.1-1.4

Tout fonctionne direct !!!
Rien d’exceptionnel (par rapport à Windows) si ce n’est que même pour le constructeur, ce n’est pas forcément censé fonctionner..

  • Introduction:

Ces deux outils de William Stearns peuvent se révéler très vite indispensable lors de la gestion de plusieurs machines…
Comme indiquer dans le titre, ces outils permettent de lançer des commandes simultanément sur plusieurs machines, et ce, même de façon interractive (avec fanterm).

  • Installation:

Je n’ai rien trouvé dans les dépôts ni en .deb. J’ai donc “aliéner” le rpm:

wget http://www.stearns.org/fanout/fanout-0.6.1-0.noarch.rpm  
sudo alien fanout-0.6.1-0.noarch.rpm  
sudo dpkg -i fanout_0.6.1-1_all.deb
  • Une petite démo sur 2 machines pour illustrer:

demo-fanterm18mars2006

fanterm-v0.6-50–18Mars2006.stearns.org

  • Pour les ssh sur des ports non standards, je suis passé par le fichier config (voir man ssh_config)
$ cat .ssh/config   
Host bipbip   
Hostname 172.16.2.200  
User yannick  
Port 2222  
  • L’authentification se fait par clé (voir man ssh)

  • J’ai remplacé xterm par Eterm dans /usr/bin/fanterm

  • Démo réalisée avec Byzanz
    Le .deb breezy trouvé sur Le StrassBlog

Ce billet présente l’utilisation de l’option -L de la commande ssh qui permet par exemple d’encapsuler dans une session chiffrée (SSH), un protocole qui passe habituellement en clair.

Pour illustrer cette option, prenons le cas ou l’on veut récupérer ses mails sur un serveur POP3 (port 110) mais sans que le mot de passe pop (ni les messages) ne passent en clair.

-L Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.

  • Le petit dessin illustrant la communication de l’exemple ci-dessous:

Yannick17Fev2005ssh-L-dessin

  • On lançe sur la machine “user” la commande SSH:
 ssh -L port-local:HOSTNAME:port-distant machine-distante
yannick@user:~$ ssh -L 1111:127.0.0.1:110 server  

…on entre le mot de passe ssh de “server”…on est connecté à “server”…

  • Il suffit ensuite de configurer notre client POP3 (Thunderbird par exemple) pour aller “poper” sur le serveur 127.0.0.1 sur le port 1111

Yannick17Fev2005ssh-L-Thunderbird

Toute la communication POP qui passe habituellement en clair est au final chiffrée.

  • La même chose en graphique avec putty:

Yannick17Fev2005ssh-L-putty

Ce billet présente l’utilisation de l’option -R de la commande ssh qui permet par exemple de monter une connexion SSH dans le sens inverse.

Pour illustrer cette option, prenons le cas ou le “support” doit prendre la main en SSH sur la machine du “client”..mais sans que le “client” ne soit contraint d’autoriser dans son FireWall une connexion entrante vers le port SSH de son serveur.

-R Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side.

  • Le petit dessin illustrant la communication de l’exemple ci-dessous:

Yannick16Fev2005ssh-R

  • Blocage de l’accès en SSH à distance vers “client” (simulation d’un FireWall)

ListenAddress 127.0.0.1 dans le /etc/ssh/sshd_config de “client”

yannick@client:~$ netstat -ant|grep 22  
tcp 0 0 127.0.0.1:22 0.0.0.0:* LISTEN   
yannick@client:~$

Il est donc impossible à une autre machine distante, de se connecter de manière “normale” sur le port 22 de “client”…

  • Rien de spécial pour l’instant sur la machine “support”:
yannick@support:~$ netstat -ant |grep 1111  
yannick@support:~$
  • On fait lançer (par le client) la commande ssh -R sur la machine “client”:
ssh -R port-distant:HOSTNAME:port-local machine-distante
yannick@client:~$ ssh -R 1111:127.0.0.1:22 support

…on entre le mot de passe de “support”…on est connecté a “support”….

  • Sur la machine “support”:

… on a désormais le port 1111 d’ouvert:

yannick@support:~$ netstat -ant |grep 1111  
tcp 0 0 127.0.0.1:1111 0.0.0.0:* LISTEN  
yannick@support:~$

…en se connectant sur le port 1111 de “support” on arrive donc sur le port 22 du “client”:

yannick@support:~$ ssh -p1111 127.0.0.1  

…demande le mot de passe de “client”…on est connecté sur le ssh de “client”

  • Fin:

Il suffira au “client” de faire exit et un CTRL+C pour couper la connexion du “support”

yannick@client:~$ Connection to 127.0.0.1 closed by remote host.  
Connection to 127.0.0.1 closed.  
yannick@support:~$
  • La même chose en graphique avec putty:

Yannick16Fev2005ssh-R-Putty

  • Il est à noter qu’il est possible de maintenir le tunnel ouvert même en quittant la session en utilisant screen.