SS...H (ssh)

encore lui, je l'adore

Les différents visages de SSH
Le 9 avril 2008, à 20:44 par Ulhume...

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.

* gaston $ssh gaston@titine
* gaston@titine $

Il ne faut pas confondre terminal et shell. Le terminal est l'outil qui gère les entrées clavier et les affichages sous la forme d'un vénérable écran texte. De manière caricaturale, un terminal est l'émulateur des anciens écrans d'ordinateur à l'époque où la souris n'existait pas encore. Un shell quant à lui est une application texte, que l'on lance pour pouvoir saisir des commandes. Le shell utilise donc le terminal pour lire les données et écrire les résultats.

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 :

* # ici je lance la commande sh à travers ssh sur la machine titine
* gaston $ssh gaston@titine "sh"
* echo $HOSTNAME
* titine
* exit

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 :
echo "Bonjour" | ssh utilisateur@machine "cat > helloWorld.txt"

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.
echo "Bonjour" | ssh utilisateur@machine "cat > helloWorld.txt ; echo merci"

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 Wink
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é Wink ). 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 Smiling

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 connectez JAMAIS un serveur SSH sur un réseau public en oubliant de désactiver les accès de l'utilisateur root. En effet si une faille est trouvée un jour sur ssh, et qu'elle est utilisée avec cet utilisateur, c'est toute votre machine qui est du coup compromise. Veillez donc à ce que le paramètre PermitRootLogin No soit bien présent dans votre fichier de configuration. Si vous tenez à pouvoir vous connecter en root à partir d'internet, allez à la technique SSH sans mot de passe dans le chapitre Améliorer la sécurité de l'accès root, il s'y trouve une bonne solution alternative.
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

Host titine
Port 12401

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 :

service ssh
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/sbin/sshd
server_args = -i
nice = 10
}

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 :

netstat -anlp | grep 22

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 926/xinetd

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.
Cette technique est très pratique mais est aussi à manier avec beaucoup de précautions. Ne jamais permettre un login sans mot de passe d'un compte utilisateur vers un compte root car si le premier est compromis (ce qui peut arriver facilement), le second l'est aussi, et là, ce peut être beaucoup plus grave !!
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 :

id gaston
# uid=500(gaston) gid=500(gaston)

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 :
chown gaston:gaston /home/gaston -Rc

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

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 :
chmod 700 /home/gaston -c

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 :
chmod 700 /home/gaston/.ssh

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

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 :

ssh-keygen -t dsa
# Appuyez sur [Entrée] à chaque question...

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 :
chmod 600 /home/gaston/.ssh/* -c

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 :
cat ~/.ssh/id_dsa.pub | ssh gaston@titine "cat >> ~/.ssh/authorized_keys"

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 :
ssh titine -R 8080:localhost:10000

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à Smiling

Alors nous avons utilisé localhost indiquant la machine l'adresse local de la machine distante (faut suivre Wink ). 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
ssh titine -R 8080:localhost:80

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 :
ssh mon_serveur -R 21:serveur_de_donnees:21

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 :
ssh titine -D 3128

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.

tu peux neutraliser l'authentification par mot de passe pour des raisons de sécurité en plaçant dans le fichier de configuration « /etc/ssh/sshd_config » la ligne « PasswordAuthentication » à « no » (et ne pas avoir « UsePAM » à « yes » !, ou autrement dit en mettant également « UsePAM » à « no »). N'oublis pas de relancer ton serveur sshd après avoir changé la configuration :

sudo /etc/init.d/ssh restart