Nous avons vu dans les articles précédents comment ssh permettait à Bob de chiffrer ses connexions aux serveurs, comment sudo permettait de restreindre et de tracer qui fait quoi, et comment screen pouvait éviter à Bob de perdre du temps. Fort des ces outils, Bob a commencé à automatiser plusieurs tâches, mais se heurte à des problèmes d'échelle : taper une fois un mot de passe passe, mais cent fois trois mots de passe ne passe plus. Nous allons voir dans cet article quelques utilisations avancées de ssh. Bob, donc, n'a pas envie de taper plusieurs fois le mot de passe pour se connecter à un serveur. Il regarde la man page de ssh, et un grand sourire illumine son visage : il a trouvé. "Ils sont forts, très forts…"

S03E01 : Socket

Bob préfèrerait éviter de jouer avec les clés publiques / clés privées : il faut les déployer partout, et pour résoudre son problème (s'authentifier plusieurs fois par serveur) il faudrait les laisser en clair sur les serveurs, ce qu'il n'aime pas beaucoup faire. Ainsi le compromis « je tape mon mot de passe une fois au lieu de trois mais je ne laisse pas mes clés en clair » lui semble acceptable pour quelques serveurs. La première option qu'il a envisagée est d'utiliser des clés privées protégées par un mot de passe et d'utiliser ssh-agent pour n'avoir à saisir qu'une fois le mot de passe pour dé-sceller la clé. Certes c'est efficace, mais Bob choisit une autre méthode...

Selon la man page, il a le choix entre modifier les commandes ssh de son script et modifier le fichier de configuration de ssh propre à l'utilisateur qui lance le script (.ssh/config depuis le répertoire home de l'utilisateur en question). Après réflexion il décide de modifier son script, car modifier le fichier de configuration impose ce dilemme :

• Faire une configuration globale, qui ne sera utile qu'un petit nombre de fois
• Faire une configuration par hôte à contacter, ce qui peut s'avérer fastidieux en fonction du nombre de machines

Il ajoute donc à la première occurrence de ssh "-MS /tmp/%l-%h-%p", puis dans les suivantes "-S /tmp/%l-%h-%p" et dans la dernière "-S /tmp/%l-%h-%p -O exit". Il relance son script, et tape le mot de passe… Une seule fois par serveur.

Quel démon du jardin magique Bob a-t-il invoqué pour que les choses se passent ainsi ?

[seti@home]~$ ssh server -MS /tmp/%l-%h-%p -Nf Password: [seti@home]~$ ls -l /tmp 0 **s**rw------- 1 gab gab 0 avril 12 18:46 home-server-22 [seti@home]~$ ssh server -S /tmp/%l-%h-%p 'ls -p' work/ recup/ [seti@home]~$ ssh server -S /tmp/%l-%h-%p -O exit Exit request sent.

L'option -S de ssh permet de définir un socket (nommé) de contrôle, -M de dire que la commande ssh correspondante en est le maître, et "-O exit" de fermer ce socket. En d'autres termes : la première commande permet à ssh de créer un socket de contrôle ; il tape son mot de passe pour se connecter à la machine distante, mais ne lance par de shell dans un premier temps (options -Nf). Les invocations suivantes de ssh utilisent ce socket et donc les informations d'authentification, et la dernière permet de fermer ce socket. La socket UNIX ainsi créée permet de piloter la session SSH qui reste résidente. Les droits associés à cette chaussette sont par défaut limités à l'utilisateur uniquement, ce qui est plutôt une bonne chose.

S03E02 : Tunnels

Baignant dans la satisfaction qui sied à tout inventeur fier de son œuvre , Bob se rappelle un épineux problème qui touche l'architecture Web de son entreprise.  Architecture qui, basiquement, peut se résumer ainsi :

Il se trouve qu'il y a un problème sur le service Web, et soupçonne la couche HTTPS apportée par le mandataire inverse de contribuer au problème. Bob se dit que s'il pouvait, du navigateur de son poste, accéder en HTTP sans 'S' au serveur Web directement, ça pourrait le faire avancer dans la résolution de ce bug.

Bien sûr, il pourrait paramétrer le reverse proxy pour qu'il accepte le HTTP ou faire de violents trous dans le pare-feu de l'entreprise. Que neni, faire des modifications dans la sacro-sainte DMZ sera vu d'un très mauvais œil, et moins il touche la configuration de l'ensemble du système, plus il a de chances de trouver le bug et de tout remettre dans l'état dans lequel il l'a trouvé.

Encore tout électrisé, et se rappelant de la man page de ssh, Bob retourne la consulter ; il croit se rappeler que ssh avait quelques options qui lui seraient bien utiles. Jusqu'à maintenant lesdites options (et surtout leur description) lui avaient parues du lorem ipsum, mais après une seconde relecture, Bob finit par comprendre qu'il y a sans doute moyen de moyenner.

Il fait quelques essais sur un poste *nix (c'est tout de même plus facile), puis fait la même chose avec son PuTTY. Il retire la configuration du proxy de son navigateur, et hop ! Il accède au serveur Web, en clair, ou du moins, comme semble le penser son butineur jovial.

Allons bon... ssh serait donc si magique pour mettre en place un serveur Web sur le poste client ?

Presque pas, mais pas très loin.

Ssh permet, entre autres, de faire des tunnels TCP : l'option -L fait que ssh écoute sur un port sur la machine client, et transmet tout ce qui lui est adressé sur ce port à la machine à laquelle il est connecté, et de cette machine à une troisième machine qu'il est possible de spécifier. Schématiquement :

Et avec un exemple en ligne de commande, depuis 'poste utilisateur' :

[seti@home]$ ssh bob@serveur1 -L 8080:serveur2:80 -Nf

Que l'on traduirait par : connecte-toi à serveur1 en tant que Bob, ouvre le port 8080 sur ma machine et transmets tout ce qu'on t'y adresse au serveur2 sur le port 80, n'exécute pas de commande distante, mets-toi en tâche de fond une fois que c'est fait. Notez que par défaut l'écoute sur le port 8080 se fait sur localhost, et que le trafic 'poste utilisateur' -> serveur1 est chiffré par ssh, alors que le trafic serveur1 -> serveur2 est en 'clair'. Pour accéder donc au serveur2 au travers de ce tunnel, Bob va donc taper dans son navigateur http://localhost:8080/.

Comble du raffinement et cauchemar des responsables sécurité, l'option -R propose exactement le même fonctionnement que l'option -L, mais en utilisant le tunnel SSH pour remonter un flux à rebrousse-poil. Cette fois-ci c'est la machine de destination (serveur1 dans notre exemple) qui se met à l'écoute de paquets entrants et qui les fait suivre au travers du tunnel SSH vers une machine accessible du poste utilisateur, ou le poste utilisateur lui-même bien entendu.

Bob, qui est maintenant depuis plusieurs jour sous ibuprofène à forte dose pour tenter de percevoir avec calme et sérénité le potentiel de ces deux options, finit par acquis de conscience la page de man et reste finalement en arrêt sur l'option -w. Cette option ne se contente plus de monter des tunnels unidirectionnels entre deux machines, elle met en place sur des machines *nix de part et d'autre des interfaces réseau virtuelles de type tun. Tout le trafic qu'il souhaite aura tout loisir de passer d'une machine à l'autre et vice-versa, pour peu qu'il ait mis en place des routes réseau adéquates. Un VPN directement utilisable en SSH, sans avoir à ouvrir de ports supplémentaires, ni à installer d'applications en plus, c'en est trop, ses nerfs lâchent.

Quizzz

Réponse au quizzz du billet précédent : screen réagit à une certaine séquence d'échappement et permet de changer le titre d'une fenêtre non-interactivement. Et d'autres termes : faites le bon echo, et screen changera le titre de la fenêtre. printf "\ekTitre\e\\" ou echo -n -e "\ekTitre\e\\" Si vous placez cette commande dans votre fichier de profile, le titre sera mis à votre fenêtre screen dès que vous vous connectez. Reste des problèmes :

• si vous ne vous connectez pas en screen le printf / echo affichera des choses pas belles,
• si dans le screen local (machine1) vous vous connectez à une autre machine (machine2) sur laquelle vous avez implémentez cette astuce, votre titre de screen (sur machine1) ne rechangera pas une fois que vous vous serez déconnecté de machine2.

Une solution est de tester la variable TERM de la session, d'agir en conséquence, et de mettre la séquence (\ekTitre\e\\) dans le prompt. Voici un exemple en bash à mettre dans votre .bashrc :

[ "$TERM" == "screen" ] && ST="\ek`hostname -s`\e\\" export PS1="[\u@\h]\w$ST "

Vous trouverez plus d'informations dans la man page de screen, section TITLES.

Conclusion

ssh, sudo et screen, au delà de tout autre outil système, rendent chaque jour d'immenses services aux administrateurs système, et leur font gagner en temps, en sécurité et en sérénité, à tel point qu'il nous semble délicat d'administrer efficacement des machines *nix sans eux. Un grand pouvoir impliquant de grandes responsabilités, ces facilités d'administration sous-entendent que vous compreniez ce que ces commandes font afin de ne pas laisser ouvert des failles (ou gouffres) de sécurité. Si vous ne connaissiez pas ces trois petits outils, nous espérons vous avoir mis l'eau à la bouche (et que, comme nous, vous ne pourrez plus vous en passer). Si vous les connaissiez, ce qui est plus probable, nous espérons vous avoir appris quelques astuces.