SSH est un utilitaire absolument vitale pour Unix, mais aussi pour Windows. Dans une première approche il permet juste d'ouvrir un terminal à distance et n'est alors pas sans rappeler le vénérable Telnet. Mais à y regarder de plus prés il se révèle sous le jour d'un véritable couteau suisse sécurisé, permettant en vrac de lancer à distance des applications graphiques, de créer des proxy sécurisés, de router tout un trafic IP sur un canal crypté, de lancer des commandes à distances,etc. En somme, outil fondamental qu'il est indispensable de maîtriser.

Du shell distant au flux sécurisé

Contrairement à ce que laisse présager son nom, le Secured Shell est un outil permettant de lancer une commande sur une machine disante, de lui fournir des données et d’en recueillir les résultats. Et tout cela au travers d'un tube crypté. Alors pourquoi donc appeler cela un Shell me direz-vous ? Tout simplement parce que la commande que lance par défaut ssh est un shell. Ainsi lorsque je tape la commande suivante, SSH m'ouvre dans mon terminal, après saisi des accréditations, un shell distant sur la machine titine en utilisant le login gaston.

Par rapport au vénérable Telnet, SSH utilisé en tant que shell présente deux interêts majeurs. Tout d'abord la sécurité car les flux sont cryptés. Ensuite la compression permettant de passer plus facilement sur des liaisons plus faibles. Mais pour se convaincre que le shell n'est en réalité qu'une commande lancée par ssh, vous pouvez essayer de la faire de manière explicite en lançant le shell bash (sh) sur la machine distante :

Comme vous l'avez vue, SSH lance une commande distante et établie un tunnel crypté entre la machine locale et la machine distante par lequel transite les données envoyées à la commandes et les résultats qu'elle renvoie. Sortons donc définitivement du cadre du simple shell pour étudier cette possibilité de tube sécurisé.

Par exemple, imaginons que nous voulions créer à distance le fichier helloWorld.txt contenant la chaîne bonjour. En utilisant SSH, la syntaxe serait la suivante :

Pour ceux qui ne sont pas à l’aise avec les tubes et les redirection, vous pouvez faire un petit tour ici.

• Tout d'abord la commande echo va écrire dans la sortie standard la chaîne de caractères "Bonjour"
• Le tube (|) redirige cette sortie vers l'entrée de la commande ssh, comme si nous avions saisi cette chaîne à la main.
• SSH va établir une connection sur la machine titine et sur le compte de l'utilisateur gaston.
• Une fois la connection établie, SSH lance la commande en paramètre cat > helloWorld.txt. Cette commande attend les données venant de son entrée standard et envoit ce qu'elle y trouve dans le fichier helloWorld.txt
• SSH va activer le tunnel et envoyer les données provenant de son entrée standard vers la commande qu'il a lancé sur la machine distante.

Pratique non ? Et nous pouvons faire la même chose dans les deux sens. Pour rendre la commande précédente un peu plus polie, faisons la remercier la machine locale.

Ici la seule différence c'est que l'on a groupé l'exécution de deux commandes en une seule (grâce au ;) la seconde ayant pour rôle d'écrire merci dans la sortie standard, ce que SSH relaye immédiatement dans son tunnel, vers la machine locale. Et comme il n'y a pas de redirection en plus, le remerciement s'affiche simplement à l'écran.

Ces deux exemples très simples vous permettent de voir que SSH est loin d'être le simple shell qui parait être. Il est possible d'effectuer grâce à lui des tâches complexes comme des backups de machines distantes vers une machine locale. Après c'est une question de besoin, d'imagination et de goût pour les legos

Paramétrage du serveur

Le démon SSH

SSH se compose d'un client (commande ssh) et d'un serveur (démon sshd). Le couple est installé en standard par l'immense majorité des distributions (désolé pour les Ubunteros mais ce n’est pas une exclusivité ). Les commandes que j'ai donné plus haut marchent donc, clef en main, sur la plupart des installations. Mais ceci n'empêche pas de changer les comportements standard pour faire coller tout cela à vos besoins.

Pour les Windowsiens, un serveur SSH est disponible dans le projet cygwin. Il marche exactement comme la version unix. Il a en plus le bon goût de s'installer en tant que service et offrir aux expatriés du monde Unix une VRAIE console

Dans la majorité des cas, la configuration de l'ensemble de la chaîne SSH se trouve dans le dossier /etc/ssh. Et plus spécifiquement celle du serveur sshd se trouve dans le fichier /etc/ssh/sshd_config. Un classique man sshd_config vous en détaillera les nombreuses options.

La plupart du temps, le serveur se lance simplement comme un service linux par un /etc/init.d/sshd start.

Ne pas utiliser le port par défaut

Le serveur se met alors par défaut en écoute du port 22. Il est malin si l'on envisage de connecter se service au réseau publique de changer se port et opter pour quelque chose de moins standard, par exemple 12401 (paramètre Port 12401 dans sshd_config). L'avantage est que vous vous mettez à l’abri des attaques automatisées. L'inconvénient est que vous devrez du coup spécifier à chaque fois ce port dans une commande ssh, par un ssh -p 12401 titine. Pour éviter cela si vous êtes amené à vous connecter souvent de la même machine, je vous conseille d'ajouter l'entrée suivante au fichier ssh_config

Cette technique vous permet d'avoir des paramètres de connections par défaut différent pour chaque serveur cible. L'entrée host * définissant le paramétrage par défaut commun à tous.

Utiliser XInetd

Normalement, lorsque l'on lance un service réseau (OpenSSH, ftp, etc...) il se met en écoute d'un port (22 pour SSH, 32 pour Ftp, etc...) et attends patiemment qu'un utilisateur veuille bien s'y connecter. Pendant ce temps, lorsque personne n'y fait appel, le service reste en mémoire et dés fois occupe aussi un peu de CPU. Xinetd est un outil qui va écouter un port à la place d'un service. Lorsqu'un utilisateur se connecte, xinetd charge le service en mémoire et le colle sur le port. Lorsque le client se déconnecte, xinetd décharge le service et libère ainsi la mémoire.

Son utilisation est qui plus est conseillée en façade à un réseau publique car finalement c'est lui qui sera du coup en première ligne, pas le serveur réel. Et vu qu'il est très simple de conception, il est aussi très sûr.

xinetd est installé en standard dans la majorité des cas. Si vous n'avez pas de /etc/init.d/xinetd vous pouvez l'installer par un simple urpmi xinetd.

Pour utiliser sshd avec xinetd, il faut simplement créer ou modifier le fichier /etc/xinetd.d/sshd-xinetd comme suit :

C'est le disable=no qui indique que le fichier est actif. Maintenant il va nous falloir arrêter le service sshd par un /etc/init.d/sshd stop et un chkconfig --del sshd pour éviter qu'il ne se relance au démarrage de la machine. Ensuite opération inverse pour xinetd : /etc/init.d/xinetd start et chkcnfig --add xinetd. ET voilà c'est tout. Et pour vérifier que c'est bien xinetd et non plus sshd qui est en écoute du port 22 :

SSH Sans mot de passe

Avertissement

A la longue c'est un peu fatiguant de rentrer un mot de passe à chaque connexion. Pour automatiser cela, OpenSSH peut remplacer l'authentification classique par un jeu clef publique/clef privée.

Préparer son compte

SSH est un outil pointilleux et encore plus lorsqu'il s'agit de se connecter sans mot de passe. La premier chose à valider est que le dossier home de l’utilisateur sur lequel on va chercher à se connecter lui appartienne vraiment. Cela peut sembler idiot mais souvent ssh manque sa connexion simplement pour cette raison. Nous allons donc tout d'abord vérifier que l'utilisateur gaston possède bien un compte et un groupe propre. Pour cela, nous utilisons la commande suivante :

Nous avons donc bien un utilisateur gaston et son groupe gaston . Nous pouvons donc vérifier que ce dossier lui appartient bien en tapant sur la machine distante :

Si la commande vous affiche des changements, c'est que l'on a bien fait de l'exécuter

Dans le même ordre d'idée, SSH n'aime pas trop que le dossier d'un utilisateur soit lisible par le reste du monde, nous allons donc vérifier que les droits sont les bons par un :

Ceci fait, nous allons nous intéresser au dossier /home/gaston /.ssh. Normalement il existe déjà, sinon, créez le. Lui aussi doit avoir des droits bien stricts que nous allons vérifier ainsi :

Pour l'instant, nous allons nous arrêter là et tenter une connexion distante par un

Si tout est bien configuré, ssh devrait vous demander le mot de passe et vous donner l'accès.

Générer un couple de clefs

Avertissement étant donné, passons à la mise en pratique. Nous voulons que gaston puisse se connecter de sa machine à la machine titine sans mot de passe. Pour cela, il faut que gaston génère sur son compte une paire de clefs et que sur son compte distant, il autorise cette clef.

La marche à suivre est donc la suivante. Tout d'abord, sur la machine locale, il faut générer un couple de clef :

Une fois terminée, vous devez avoir dans le dossier /home/gaston/.ssh deux clefs : id_dsa et id_dsa.pub. Pour que ssh les accepte, nous devons en modifier les droits :

Ceci fait, nous allons recopier la clef PUBLIQUE, c'est-à-dire id_dsa.pub dans le fichier /home/gaston/.ssh/authorized_keys de la machine distante. Ce fichier peut contenir plusieurs clefs, les unes dernières les autres, une ligne à chaque fois.

Pour copier cette clef, soit vous utilisez le bon vieux presse-papiers, soit vous utilisez ce que nous avons vu sur ssh au chapitre précédent :

Cette ligne magique va vous demander (une dernière fois) le mot de passe sur la machine distante et y expédier ensuite, via ssh, le contenu de la clef publique. Le > > permet de ne pas écraser les clefs déjà stockées dans le fichier.

Voilà, c'est terminé, il ne suffit plus qu'à tester votre nouvelle connexion sans mot de passe. En ajoutant un paramètre à ssh, il est aussi possible de mettre de prendre les clefs ailleurs sur sur ~/.ssh/, par exemple sur une clefs usb, et ainsi de les garder avec vous en permanence.

Améliorer la sécurité de l'accès root

Cette technique de la connexion sans mot de passe peut être très utile pour améliorer la sécurité d'un serveur SSH connecté au réseau publique. En effet, comme nous l'avons vu plus haut, il est irresponsable de laisser à root le droit de se connecter sur un serveur ssh à partir d'internet. Il n'y a pas de failles connues à ce jour sur ce point mais nul ne sait ce qu'il peut arriver. Mais si vous tenez à pouvoir vous connecter en root sur un serveur SSH publique, la bonne solution consiste à utiliser justement un couple de clefs et à paramétrer le serveur distant pour qu'il refuse la connexion par mot de passe et donc n'accepte QUE la connexion par clef.

Il va sans dire que la règle énoncée plus haut tient toujours, ne faite ce genre de chose qu'entre deux comptes root, pas entre celui d'un utilisateur standard et le root. Je me répète, je sais, mais bon.

Pour indiquer au serveur SSH de refuser toute méthode d'authentification autre que celle de la clef, il suffit simplement de modifier le fichier /etc/ssh/sshd_config et de modifier le paramètre PermitRootLogin "without-password". Bien évidemment, il faut relancer le serveur après cette modification.

Redirections de ports

Redirection d'un port distant sur un port local

Nous avons vu que SSH fonctionnait comme un tunnel sécurisé permettant de faire passer de manière des données d'une commande à une autre, l'une locale, l'autre distante. Mais ce ne serait pas rendre hommage à cet outil que de le limiter à ce simple usage.

En effet, ssh est parfaitement capable de faire la même chose mais directement sur un port TCP/IP cette fois. Imaginons un cas classique. J'ai un réseau local utilisant webmin . Ce dernier est un serveur WEB utilisant le port 10000. Or je n'ai pas très envie de publier ce port sur un réseau publique, et pourtant pouvoir accéder à cette interface d'administration à distance peut-être très utile. La solution ? Passer par un routage de port avec ssh :

Une fois la commande exécutée et la connexion établie, si vous prenez votre navigateur WEB et allez à l'adresse localhost:8080 (le port 8080 de VOTRE machine locale), la requête va transiter par ssh et être effectuée sur le serveur distant au port localhost:10000. Le résultat de la requête va revenir par le même chemin et s'afficher sur votre navigateur. Et voilà

Alors nous avons utilisé localhost indiquant la machine l'adresse local de la machine distante (faut suivre ). Mais cette commande permet d'atteindre toutes les machines du réseau local qui contient ma machine distante. A méditer très sérieusement lorsque vous ouvrez benoîtement un accès ssh à un tiers... A noter cependant qu'il est possible d'interdire au niveau du serveur la redirection de port par le paramètre AllowTcpForwarding. Ceci dit, comme l'indique la documentation de ssh, ce n'est que reculer pour mieux sauter car quelqu'un qui dispose d'un accès ssh peut installer son propre système de redirection, à bon entendeur...

Redirection d'un port local sur un port distant

Il est aussi possible par ssh d'effectuer l'opération inverse et ainsi autoriser la machine distance à se connecter sur un serveur de votre lan

Cette commande n'a l'air de rien, mais imaginez dans un contexte d'entreprise. Un simple employé peut lancer une série de client ssh qui vont ainsi rendre ses machines disponibles, à l'extérieur du réseau. Imaginez le gag que peut être une commande du genre :

Avec cela, n'importe qui peut se connecter sur le serveur FTP privé de l'entreprise comme s'il était dans le LAN. Pensez-y avant d'ouvrir l'accès SSH dans votre firewall…

Redirection globale via SOCKS

SSH complète la panoplie du tunnel crypté multi usage par un outil de poids : un proxy SOCKS.

Un proxy SOCKS est petit serveur utilisant un protocole conçu pour à une application qui sait l'utiliser (un navigateur WEB, un messenger, un client FTP, etc..) de se connecter sur le net sans avoir directement de connexion à internet. Toutes les demandes de l'application vont donc passer par le proxy SOCKS.

Un proxy SOCKS se distingue d'un Proxy HTTP en le fait qu'il n'est pas spécialisé à un seul protocole (contrairement au cas précédents) mais va router globalement le trafic qu'il soit FTP, HTTP, POP, etc...

Pour utiliser une machine distante comme passerelle internet et la machine locale comme proxy socks, il me suffit donc de lancer la commande suivante :

Et si je configure par exemple FireFox pour utiliser le serveur SOCKS localhost:3128, je vais pouvoir, à travers la connexion SSH, utiliser la connexion Internet de la machine distante sans aucune limite. Je peux aller sur n'importe quelle machine du réseau distant, je peux aussi utiliser la connexion Internet du réseau distant. Bref, faire à peu près ce que je veux. La aussi, c'est le genre de chose à méditer avant de donner sans réfléchir un accès ssh sur une machine.

Conclusion

Ce rapide tour d'horizon nous a permis de voir à quel point SSH est un outil versatile et souple. Et dangereux aussi. A manier donc avec d'infinies précautions dès qu'il s'agit d'ouvrir un accès ssh sur votre machine, ou de laisser passer ssh sur un firewall.

Commentaires