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.
L'implémentation la plus complète du protocle SSH sur GNU/Linux
L'implémentation du protocole qui est intégrée aux distributions linux s'appelle openSSH et est développée par l'équipe d'OpenBSD sous la direction de Théo de Raadt, et est scindée en deux paquets : openssh-server et openssh-client dont le nom indique clairement la fonction. Le chiffrement des données repose sur la méthode dite chiffrement assymétrique, utilisant un jeu de "clés" publique/privée de structure particulière, dites souvent clés Diffie/Hellman du nom des deux chercheurs, Whitfield Diffie et Martin Hellman, ayant publié le premier article concernant ce type de cryptographie en 1976.
Comme dans la plupart des informations et explications de ce site concernant GNU/Linux, nous utiliserons la distribution Debian. Mais, en dehors des commandes d'installation des paquets; les informations seront valables pour la quasi totalité des distributions Linux généralistes.
Si vous louez un serveur chez un prestataire comme Online, OVH etc. le serveur SSH sera installé par défaut car la première connexion se fera par SSH (sauf peut-être si vous commandez un panel type Plesk, mais ceci n'est pas pris en compte dans ce guide).
Si le serveur SSH n'est pas installé, il suffit d'installer le paquet openssh-server. Sur les distributions Debian et dérivées :
Il suffit d'installer le paquet openssh-client, qui contient entre autre les utilitaires ssh-agent et ssh-add utiles pour alléger le maniement des clés chiffrées par passphrase. Pour l'installation reportez-vous à la documentation du gestionnaire de paquet de votre distribution. Sur Debian et dérivés un simple :
il existe de nombreux cas de figure où l'on veut offrir un accès SSH à des utilisateurs sur un serveur pour une utilisation bien précise sans leur accorder de droits en dehors de cette utilisation ciblée. C'est par exemple le cas lorsque l'on veut concéder un accès MySQL au travers d'un tunnel SSH, donner accès à un dépôt CVS etc.
La difficulté
La contrainte posée par SSH est que pour se connecter l'utilisateur doit disposer d'un compte unix sur la machine serveur SSH. Si vous lui créez un compte utilisateur classique, disposant d'un shell, même limité, l'utilisateur pourra se loguer sur le serveur comme un utilisateur normal de la machine. Ce n'est pas toujours souhaitable.
Il faut donc disposer d'un moyen de laisser l'utilisateur se connecter à une application serveur spécifique et rien d'autre.
La solution
Pour pouvoir appliquer cette solution il faut impérativement que l'identification sur le serveur SSH se fasse par un jeu de clés Diffie/Hellman. L'utilisateur n'a pas à saisir de mot de passe mais doit avoir fourni sa clé publique pour qu'elle soit installée sur le serveur.
La procédure de connexion par clés (expliquée ici) consiste, sur le serveur SSH, à stocker les clés des utilisateurs autorisés à utiliser un compte sur le serveur dans un fichier (conventionnellement le fichier $HOME/.ssh/authorized_keys de l'utilisateur de connexion) qui sera consulté lors des tentatives de connexion de l'utilisateur pour son identification et l'acceptation ou non de sa connexion.
C'est dans ce fichier que plusieurs options de sshd, le démon SSH, va permettre de limiter les accès d'un utilisateur.
FORMAT DU FICHIER AUTHORIZED_KEYS
$HOME/.ssh/authorized_keys est le fichier par défaut qui liste les clefs publiques autorisées pour l'authentification RSA
pour la version 1 du protocole, et pour l'authentification par clef publique (PubkeyAuthentication) pour la version 2 du protocole.
On peut utiliser l'option AuthorizedKeysFile pour spécifier un autre fichier de configuration.
Chaque ligne du fichier contient une clef (les lignes vides ou débutant par le caractère « # » sont ignorées et considérées comme des commentaires).
Chaque clef publique RSA consiste en les champs suivants, séparés par des espaces : options, bits, exposant, modulo, commentaire.
Chaque clef publique pour la version 2 du protocole consiste en : options, type de clef, clef encodée en base64, commentaire.
Les champs d'option sont optionnels ; leur présence est déterminée par le fait que la ligne commence avec un nombre ou pas
(le champ d'option ne commence jamais par un nombre). Les champs bits, exposant, modulo et commentaire déterminent la clef RSA pour la version 1 du protocole ;
le champ commentaire n'est pas utilisé pour quoi que ce soit (mais peut servir à l'utilisateur pour identifier sa clef).
Pour la version 2 du protocole, le type de clef est « ssh-dss » ou «ssh-rsa ».
Note : les lignes contenues dans ce fichier font en général quelques centaines de caractères (à cause de la taille du modulo de la clef RSA).
Il n'est pas très judicieux de les saisir manuellement ; il est plus fiable de les copier dans les fichiers identity.pub id_dsa.pub ou id_rsa.pub puis de les coller.
sshd impose une taille minimale du modulo pour la clef RSA pour la version 1 du protocole et pour les clefs pour la version 2 du protocole de 768 bits.
Les options (s'il y en a) consistent en une liste d'entrées séparées par des virgules. Les espaces sont interdits, sauf entre des guillemets.
Les spécifications d'options suivantes sont supportées. Note : les mots-clefs des options ne sont pas sensibles à la casse.
[...]
from=pattern-list
Spécifie qu'en plus de l'authentification RSA, le nom canonique de la machine distante doit figurer dans la liste des motifs séparés par des virgules (« * » et «? » sont des jokers). La liste peut aussi contenir des motifs précédés par l'opérateur de négation « ! » ; si le nom canonique de la machine correspond au motif nié, on n'accepte pas la clef. Le but de cette option est éventuellement d'améliorer la sécurité : l'authentification RSA en elle-même ne permet pas d'avoir confiance dans le réseau ou les serveurs de noms ou quoi que ce soit (à part la clef) ; par contre, si quelqu'un vole la clef, cette clef lui permet de se connecter depuis n'importe où dans le monde. Cette option supplémentaire rend encore plus difficile l'utilisation d'une clef volée (les serveurs de noms et/ou les routeurs peuvent avoir été compromis en plus de la clef elle-même).
command=commande
Spécifie que cette commande doit être exécutée si on utilise cette clef pour s'authentifier. La commande fournie par l'utilisateur (s'il y en a une) est ignorée. La commande est exécutée sur un pseudo-terminal (pty) si le client a demandé un pseudo-terminal ; sinon elle est exécutée sans terminal. Si on a besoin d'un canal 8-bits propre, on ne doit pas demander de pseudo-terminal, ou alors on spécifie no-pty On peut inclure une apostrophe (« ' ») dans la commande en la faisant précéder d'une anti-barre (« \ »). Cette option peut être utile pour restreindre à des actions spécifiques. Par exemple, une clef peut n'autoriser qu'à effectuer des sauvegardes distantes, mais rien d'autre. Note : le client doit spécifier des redirections TCP/IP ou X11 sauf s'ils sont explicitement interdits. Cette option s'applique à l'exécution d'un interpréteur de commandes (shell), d'une commande ou d'un sous-système.
environment=NAME=value
Spécifie que la chaîne de caractère doit être ajoutée à l'environnement lors de la connexion en utilisant cette clef. Les variables d'environnement définies de cette manière outrepassent les autres variables d'environnement par défaut. On peut spécifier plusieurs de ces options. Cette option est désactivée automatiquement si l'option UseLogin est activée.
no-port-forwarding
Interdit les redirections TCP/IP si on utilise cette clef pour l'authentification. Toute demande de redirection de port de la part de l'utilisateur retournera une erreur. Ceci peut être utilisé par exemple pour une connexion avec l'option command
no-X11-forwarding
Interdit les redirections X11 si on utilise cette clef pour l'authentification. Toute demande de redirection X11 de la part de l'utilisateur retournera une erreur.
no-agent-forwarding
Interdit les redirections de l'agent d'authentification si on utilise cette clef pour l'authentification.
no-pty
Empêche l'allocation de terminal (toute demande d'allocation d'un terminal virtuel échouera).
permitopen=host:port
Limite les redirections de port « ssh -L » locales de telle manière qu'il n'est possible de se connecter qu'à la machine et au port spécifiés. On peut spécifier des adresse IPv6 avec une autre syntaxe : host/port On peut spécifier plusieurs options permitopen en les séparant par des virgules. Aucune correspondance n'est effectuée sur les noms de machines, ils doivent être des adresses ou des domaines littéraux.
C'est donc l'option command des options de saisie de clé dans $HOME/.ssh/authorized_keys qu'il va falloir utiliser. En prenant l'exemple d'un accès réduit à MySQL il faudra placer en tête de la clé de l'utilisateur la mention command="/usr/bin/mysql", celui-ci n'aura alors accès qu'à MySQL. La clé copiée dans le fichier ressemblera à quelque chose de ce genre :
Comme indiqué dans le manuel, le champ user_machin est un champ de commentaire libre autorisé par sshd qui permet de placer un élément d'identification permettant de savoir à qui appartient la clé publique, ce qui est utile si elles sont nombreuses dans le fichier.
Il ne faut pas omettre les apostrophes autour du nom de la commande.
Dans le cas où vos utilisateurs s'identifient par mot de passe
C'est à priori une méthode à proscrire sur un serveur en production relié à Internet (voir ici). Mais on peut simuler un comportement semblable à celui de la configuration précédente en procédant comme suit.
ATTENTION : Cela reste du bricolage et vous ne devriez en aucun cas l'utiliser en production ! Vous êtes prévenus...
Vous créez un compte user_ssh sur la machine pour donner un accès ssh à vos utilisateurs sur la machine. Pour que ce compte ne donne accès qu'à une commande particulière il faut fournir comme shell à l'utilisateur créé un fichier qui contiendra la commande en question. On utilise l'option --shell de l'utilitaire de création de comptes adduser en lui communicant par exemple la valeur suivante : /home/user_ssh/.lance_commande de manière à obtenir la ligne suivante dans /etc/passwd :
