Pourquoi utiliser SSH ?

Les intrus potentiels disposent de divers outils leur permettant de perturber, intercepter et réorienter le trafic réseau afin d'accéder à un système. De manière générale, ces menaces peuvent être classées comme suit :

Interception de la communication entre deux systèmes

L'attaquant peut se trouver quelque part sur le réseau entre les parties en communication, copiant toute information passée entre elles. Il peut intercepter et conserver les informations, ou les modifier et les transmettre au destinataire. C'est ce que l'on appelle l'attaque de l'homme du millieu (en anglais MITM, Man In The Middle Attack). 

Cette attaque est généralement réalisée à l'aide d'un renifleur de paquets, un utilitaire réseau assez courant (sous Linux tdpcump ou whireshark par exemple) qui capture chaque paquet circulant sur le réseau et analyse son contenu. Sur les anciens réseaux à concentrateur (hub) la technique était enfantine, sur un réseau actuel utilisant généralement un commutateur (switch) la technique demande une autre étape, comme l'empoisonnement ARP, mais reste tout de même assez facile à mettre en oeuvre.

Usurpation de l'identité d'un hôte particulier (spoofing)

Le système de l'attaquant est configuré pour se faire passer pour le destinataire d'une transmission. Si cette stratégie fonctionne, le système de l'utilisateur ne sait pas qu'il communique avec le mauvais hôte.

Cette attaque peut être réalisée à l'aide d'une technique connue sous le nom d'empoisonnement du DNS, ou via ce que l'on appelle l'usurpation d'adresse IP. Dans le premier cas, l'intrus utilise un serveur DNS craqué pour pointer les systèmes clients vers un hôte dupliqué de manière malveillante. Dans le second cas, l'intrus envoie des paquets réseau falsifiés qui semblent provenir d'un hôte de confiance.

Les deux techniques interceptent des informations potentiellement sensibles et, si l'interception est faite pour des raisons hostiles, les résultats peuvent être désastreux. Si SSH est utilisé pour la connexion à distance au shell et la copie de fichiers, ces menaces de sécurité peuvent être considérablement réduites. En effet, le client et le serveur SSH utilisent des signatures numériques pour vérifier leur identité. De plus, toutes les communications entre les systèmes client et serveur sont chiffrées. Les tentatives d'usurpation de l'identité des deux parties d'une communication ne fonctionnent pas, puisque chaque paquet est chiffré à l'aide d'une clé connue uniquement des systèmes local et distant.

Le protocole SSH apporte les garanties suivantes

Personne ne peut se faire passer pour le serveur ciblé

Après une première connexion, le client peut vérifier qu'il se connecte au même serveur que celui auquel il s'était connecté précédemment.

Personne ne peut s'emparer des informations d'authentification

Le client transmet ses informations d'authentification au serveur en utilisant un chiffrement fort (qui évolue pour s'adapter à la monté en puissance de calcul des machines, maintenant 256 ou 512 bits).

Personne ne peut intercepter la communication

Toutes les données envoyées et reçues au cours d'une session sont transférées en utilisant un chifrement de 256 ou 512 bits, ce qui rend les transmissions interceptées extrêmement difficiles à déchiffrer et à lire.

Il offre également les options suivantes

Il fournit des moyens sécurisés d'utiliser des applications graphiques sur un réseau

Grâce à une technique appelée X11 forwarding, le client peut faire suivre les applications X11 (X Window System) du serveur. Ceci peut tout de même amoindrir la sécurité, par exemple si vous réglez l'option ForwardX11Trusted sur oui ou que vous utilisez SSH avec l'option -Y, vous contournez les contrôles de l'extension X11 SECURITY, ce qui peut entraîner une menace pour la sécurité. Je n'aborderai pas ce point sur ce site.

Il fournit un moyen de sécuriser des protocoles autrement peu sûrs

Le protocole SSH chiffre tout ce qu'il envoie et reçoit. Grâce à une technique appelée "port forwarding", un serveur SSH peut devenir un moyen de sécuriser des protocoles par ailleurs peu sûrs, comme le protocole POP, et d'accroître la sécurité globale du système et des données.

Il peut être utilisé pour créer un canal sécurisé

Le serveur et le client OpenSSH peuvent être configurés pour créer un tunnel similaire à un réseau privé virtuel pour le trafic entre les machines serveur et client.

Il supporte l'authentification Kerberos

Les serveurs et clients OpenSSH peuvent être configurés pour s'authentifier en utilisant l'implémentation GSSAPI (Generic Security Services Application Program Interface) du protocole d'authentification du réseau Kerberos. Je n'aborderai pas ce point sur ce site.

Que peut-on faire avec ssh ?

Une grande quantité de choses. La plus courante est d'admnistrer une machine à distance. Mais on peut égalment utiliser un montage de répertoire distant avec sshfs, se connecter à un service comme un serveur SQL dans un tunnel chiffré, synchroniser des répertoires avec rsync etc.

Nous allons avec quelques exemples survoler ces types d'utilisation avant, dans les chapitre suivants, d'entrer dans les détails de configuration de la partie client et de la partie serveur, jusqu'à des utilisations assez pointues autorisées par les versions modernes d'openSSH.

Administrer son serveur GNU/Linux à distance

L'administration d'un serveur GNU/Linux se fait généralement à distance via le réseau, car le serveur est situé dans un datacentre et que l'on n'a pas d'accès physique à la machine.

Il existe alors deux options, soit utiliser un panel (Vitualmin/Webmin, ISPConfig, cPanel, Plesk etc.), soit utiliser la ligne de commande. Et même si vous utilisez un panel d'administration il arrivera que vous devrez vous connecter en ligne de commande sur votre serveur.

Et pour utiliser la ligne de commande il faut pouvoir se connecter sur la machine et obtenir un shell. Ce type de connexion réseau, qui dans les premiers temps d'Unix se faisait via Telnet et rsh (c'est à dire avec une connexion en clair via le réseau), se fait maintenant depuis plusieurs décennies avec le protocole chiffré SSH.

SSH remplace nous l'avons dit les protocoles telnet, rlogin, rsh et rcp en ajoutant une sécurité, totalement absente de ces protocoles (un mot de passe transitant via telnet ou rlogin circule en clair sur le réseau). Si l'on considère un serveur du nom de serveur.tld on a les équivalents suvants pour les anciens qui se souviennent encore de ces commandes oubliées :

Équivalent chiffré de rlogin

$ ssh serveur.tld

Équivalent chiffré de rsh

$ ssh serveur.tld ls -l

Équivalent de rcp

scp serveur.tld:/et/group /tmp

Pour pouvoir utiliser ssh pour se connecter à une machine il faut disposer d'un accès à un compte utilisateur sur cette machine. Disposer d'un accès signifie connaître le nom de connexion de cet utilisateur (login) et son mot de passe (nous verrons plus tard l'utilisation des clés de connexion).

De ce qui précède on peut tirer la conclusion qu'il est préférable de désactiver ces anciens outils pour ne pas risquer de faire par erreur transiter en clair un mot de passe qu'on avait précautionneusement réussi à cacher avec ssh. Bien que dans la pratique il soit préférable d'abandonner les mots de passe pour ne plus utiliser que des clés de connexion. En effet un outil comme telnet garde son intérêt pour tester et simuler des protocoles réseau.

Il faut bien entendu également que le serveur soit configuré pour accepter ce type de connexion. Dans tous nos exemples nous allons supposer qu'il existe un utilisateur toto sur la machine serveur.tld à laquelle nous voulons nous connecter.

Connexion à distance comme le faisait rlogin

Pour obtenir un accès console deux syntaxes :

ssh -l toto serveur.tld

ou bien

ssh toto@serveur.tld

SSH écoute par défaut sur le port 22, mais on peut le faire écouter sur n'importe quel port. Si le port par défaut n'est pas 22 mais disons 2223, alors les commandes de connexion deviennent ;

ssh -l toto serveur.tld -p 2223

ssh toto@serveur.tld -p2223

Lors de la première connexion un message apparaît demandant si l'on reconnaît la clé présentée par le serveur. Pour l'instant nous allons dire que oui. Puis un prompt apparaît demandant de saisir le mot depasse de l'utilisateur toto. Si nous le connaissons et le saisissons sans erreur nous nous retrouvons alors dans le shell de l'utilisateur toto. Et nous pouvons lancer toutes les commandes que peut lancer cet utilisateur. Si ce dernier à des droits sudoers, nous pouvons même par exemple devenir root pour effectuer des tâche d'administration système. À chaque connexion ssh va nous demander ce mot de passe.

Lancer une commande comme le faisait rsh

Mais nous n'avons pas forcemment besoin de nous connecter en console sur le serveur. Admettons que vous vouliez savoir si serveur.tld est synchronisé à des serveurs de temps en utilisant ntp, vous pouvez taper  dans votre console :

ssh toto@serveur.tld "ntpq -p"

et après saisie du mot de passe voir :

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
+cluster009.lino 193.190.230.37   2 u  196 1024  377    2.224    0.145   0.221
*dedibox.demonge 145.238.203.14   2 u  344 1024  377    5.141    0.184   0.569
+27.ip-51-68-44. 195.154.174.209  3 u  695 1024  377    0.613   -0.002   0.266
-berlix.fraho.eu 131.188.3.220    2 u  810 1024  377    0.502    0.285   0.127
-ip139.ip-5-196- 10.21.137.1      2 u 1025 1024  377    2.088    1.512   0.847

Copier un fichier comme le faisait rcp

Vous avez fait un script que vous voulez lancer en tâche cron de l'utiisateur Toto. Pour faire exécuter ce script sur le serveur vous avez besoin de le copier dans le répertoire de toto. Si ce script s'appelle mysqldump.sh et se situe dans un répertoire mes_scripts de votre compte local vous pouvez le copier sur serveur.tld :

scp /home/moi/mes_scripts/mysqldump.sh toto@serveur.tld:/home/toto/

Il faut que les répertoires de destination existent réellement. Après saisie du mot de passe vous allez voir un affichage de la progression de l'envoi du fichier. Et si vous vous connectez vous verrez dans /home/toto votre script.

SSH permet également d'effectuer des sauts de serveur. Vous vous connectez via ssh sur un serveur puis depuis ce serveur vous ouvrez une connexion ssh vers un troisième et de ce troisième vers un quatrième etc. C'est très utile pour par exemple tester des règles de contrôle de connexion suivant divers hôtes. C'est aussi cette particularité qui sous-tend l'utilisation de bastions SSH.

Tunnelisation

Un autre intérêt majeur de SSH est sa capacité à chiffrer n'importe quelle communication sur un port TCP entre deux machines distantes, réalisant ainsi un tunnel chiffré protégeant les échanges de données d'un éventuel « sniffage » de réseau. Il est ainsi possible de se connecter à un serveur de courrier, une base SQL etc. de façon sécurisée dans ce type de tunnel. De plus la tunnelisation SSH permettant des translations de port, les services sur le serveur n'ont pas besoin d'exposer à Internet les ports qu'ils utilisent. Nous verrons cela plus bas avec l'exemple d'une connexion à un serveur MySQL/MariaDB.

Une utilisation classique est la sécurisation de protocoles non naturellement sécurisés comme POP3 pour le courrier. En ouvrant un tunnel ssh vous faites transiter la communication POP dans ce tunnel.  (POP3 est plus généralement sécurisé par l'autre grand protocole TLS/SSL car il n'est pas courant que tous les utilisateurs POP3 aient un compte sur la machine.).

Un autre exemple d'utilisation qui peut rendre de grands services est d'accéder à une base de données, par exemple MySQL, sur un serveur distant sans exposer le port MySQL (3306 par défaut) sur Internet.

Si votre serveur MySQL (ou Mariadb) écoute sur le réseau via son port 3306 mais qu'une règle de pare-feu bloque tout accès depuis Internet, vous pourrez tout de même vous connecter à distance en profitant de la caractéristique d'un tunne SSH de se connecter via un port SSH puis de basculer sur un autre port du serveur distant.

En postulant que votre port SSH par défaut (port 22) soit ouvert sur Internet et que votre serveur SQL écoute sur 3306 alors que l'accès à ce port est bloqué par le firewall vous pourrez vous connecter avec la commande suivante :

ssh -N -f user@serveur.tld -p 22 -L 35000:serveur.tld:3306

La signification des options est la suivante :

-N

On n'exécute pas de commande distante, on translate juste un port.

-f

On demande que le processus soit passé en arrière plan

-p

Indique le numéro du port SSH à utiliser (ici celui par défaut)

-L

Indique un formart de port qui est donné par la chaîne qui le suit.

35000:serveur.tld:3306

Translation du port local 35000 vers le port distant 3306 via SSH. Ce numéro de port 35000 est arbitraire. Ce pourrait être 3306 si l'on est certain qu'en local aucun service MySQL n'écoute dessus.

Toute requête MySQL envoyée sur le port 35000 sera transmise au serveur distant sur le port 3306 en passant par le port 22. Dans cette configuration l'utilisateur MySQL avec lequel vous vous connectez à la base devra être configuré pour autoriser les connexions depuis le port local de la machine (127.0.0.1). Pour MySQL/MariaDB, la connexion via le tunnel SSH semblera être une connexion TCP locale.

Monter un répertoire distant avec sshfs

Vous avez besoin d'éditer et modifier différents documents texte situés dans le répertoire de toto sur la machien distante. Vous pouvez vous connecter sur la machine et éditer ces fichiers avec un éditeur en ligne de commande comme vim, nano, joe etc. Vous pouvez aussi monter le répertoire de toto sur votre machine et accéder à ses fichiers avec un éditeur de texte graphique sur votre poste de travail (comme Kate, Kwrite, Gedit par exemple). Pour cela il faudra que vous installiez l'utilitaire fuse et sshfs. Ce dernier implémente un système de fichier réseau reposant sur ssh. Ce système est en espace utilisateur (grâce à fuse) vous permettant de faire le montage sans être root. Vous pouvez donc faire :

mkdir montagetoto
sshfs toto@serveur.tld:/home/toto/ /home/monuser/montagetoto/

et lorsque vous afficherez le contenu de ~/montagetoto/ vous verrez les fichiers et dossiers de la machien distante, via ssh par un montage chiffré sur le réseau.

Attention cependant, sshfs est mono-utilisateur. Il n'a pas comme CIFS/SAMBA ou NFS de mécanisme de gestion des accès concurrents. Et si un répertoire est monté en sshfs par deux utilisateurs, et que chacun de ces utilisateurs modifie le même fichier, celui qui enregistrera en dernier écrasera les modifications de l'autre (sauf si l'éditeur repère que le fichier a été modifié, mais ce ne sera pas sshfs qui gèrera cela).

Synchroniser des fichiers à distance dans une connexion sécurisée avec rsync et ssh

Si vous voulez maintenir une copie mirroir des fichiers de toto sur votre machine locale, vous pouvez utiliser scp comme vu plus haut, mais il est préférables d'utiliser rsync qui sait ne télécharger que les données nouvelles ou qui ont été modifiées. Une commande comme :

rsync -vrlptgD -e "/usr/bin/ssh" toto@seveur.tld:/home/toto/ ~/monbackuptoto/

sauvera les données de toto dans le répertoire ~/monbackuptoto de votre machine en se connectant en ssh  en conservant les heures et attributs des dossiers et fichers. Et si vous la lancez tous les jours elle ne téléchargera que les nouveaux fichiers ou les fichiers ayant été modifiés.

Nous allons approfondir toutes ces notions dans les chapitres suivants.

En savoir plus sur le protocole SSH

Le protocole SSH est décrit dans une série de documents produits sous l'égide de l'IETF (site de l'IETF) connus sous le nom de RFC (Requests For Comments qui signifie littéralement « demande de commantaires »). Les RFC intimident souvent beaucoup les novices. Ce sont des documents techniques en anglais considérés comme difficiles. Si vous êtes administrateur système ou réseau vous ne pourrez faire l'économie de la lecture de quelques RFC. Si vous êtes simplement curieux de comprendre un peu les arcanes d'Internet vous pourrez également avec profit lire quelques RFC. Leur lecture n'est pas toujours aussi difficile qu'on le dit, ces textes sont même souvent des monuments de clareté et donnent toute la mesure de la somme d'intelligences qui ont été réunies pour faire de l'Internet ce qu'il est.

Les RFC concernant SSH sont particulièrement intéressantes et lisibles (sauf peut-être les parties concernant les aspects cryptographiques demandant des connaissances en cryptologie).

La liste des RFC concernant le protocole SSH figure sur le site de l'IETF : RFC pour SSH.