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é

Comme le laisse entendre son nom, le Secured Shell est un outil permettant, à travers une connexion sécurisée, de lancer une shell (généralement un bash) sur une machine distante, de lui fournir des données et d’en recueillir les résultats. 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

gaston@titine 

Exemple de connexion simple

La première chose qui se passe ici est un tunnel chiffré entre le client SSH local et le serveur SSH distante. Tout ce qui arrive par l'entrée standard du client est expédié vers le serveur et tout ce qui est reçu par le serveur est envoyé vers la sortie standard du client.

A l'autre bout, le serveur SSH lance un shell. Il injecte dans son entrée standard tout ce qui est reçu et expédie tout ce qui est émis sur la sortie standard du shell. En résulte un bash distant "télécommandé" à travers un tube chiffré.

Par défaut, le serveur SSH ne lance qu'un simple bash. Mais il est possible, par le biais du client, de lui demander de lancer une commande au sein même de ce bash. Attention, j'ai bien dit au sein du bash, pas en remplacement.

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

gaston$echo "Bonjour" | ssh utilisateur@machine "cat > helloWorld.txt"

gaston$ 

Exemple de redirection simple

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

1. La commande echo va écrire dans la sortie standard la chaîne de caractères "Bonjour".
2. Le tube (|) redirige cette sortie vers l'entrée du client ssh, comme si nous avions saisi cette chaîne à la main.
3. SSH va établir une connection sur la machine titine et sur le compte de l'utilisateur gaston.
4. Une fois la connection établie, le serveur SSH lance un bash auquel il ajoute le paramètre -c cat > helloWorld.txt. Cette commande ne fait qu'attendre les données venant de son entrée standard et envoie ce qu'elle y trouve dans le fichier helloWorld.txt

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 répondre la machine distante.

gaston$echo "Bonjour" | ssh utilisateur@machine "cat > helloWorld.txt ; echo 'Bien le bonjour à vous'"

Bien le bonjour à vous

gaston$ 

Exemple de redirection simple avec réponse

Ici la seule différence est que l'on a groupé l'exécution de deux commandes en une seule (grâce au ;). La seconde ayant pour rôle de répondre 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 légos

Paramétrage du serveur

En passant directement par 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. Les commandes que j'ai données 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.

En passant par xinetd

Normalement, lorsque l'on lance un service réseau (OpenSSH, ftp, etc...) il se met en écoute d'un port (22 pour SSH, 21 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 parfois 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 public 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
}

configuration d'XInetd pour SSH

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 :

root#netstat -anlp | grep 22

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

root# 

Vérification du lancement d'Xinetd pour SSH

SSH Sans mot de passe

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.

SSH est un outil pointilleux et encore plus lorsqu'il s'agit de se connecter sans mot de passe. La première 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 :

root#id gaston

uid=500(gaston) gid=500(gaston)

root# 

Vérification de l'utilisateur

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 :

root#chown gaston:gaston /home/gaston -Rc

root# 

Vérification des bons propriétaires

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 :

root#chmod 700 /home/gaston -Rc

root# 

Vérification des bons droits

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 :

root#chmod 700 /home/gaston/.ssh

root# 

Vérification des droits sur .ssh

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

root#ssh gaston@titine

gaston@titineexit

root#

root# 

Tentative de connexion

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

Nous voulons maintenant 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 :

gaston$ssh-keygen -t dsa

Appuyez sur [Entrée] à chaque question...

gaston$ 

génération de la paire de clefs

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 :

gaston$chmod 600 ~/.ssh/* -c

gaston$ 

Vérification des droits sur les clefs

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 un script fourni en standard avec ssh :

gaston$ssh-copy-id gaston@titine

gaston$ 

Transmission de la clef

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.

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 ~/.ssh/, par exemple sur une clefs usb, et ainsi de les garder avec vous en permanence.

Redirections de ports

Redirection d'un port distant vers un port local

Nous avons vu que SSH fonctionnait comme un tunnel sécurisé permettant de faire passer de manière chiffrée 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 public, 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 :

10000 vers le port local localhost:8080":

gaston$ssh titine -L 8080:localhost:10000

gaston@titine

gaston@titine 

Une fois la commande exécutée et la connexion établie, si vous prenez votre navigateur WEB et que vous 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...

Redirection d'un port local vers 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

10000 sur le port distant titine:8080":

gaston$ssh titine -R 8080:localhost:10000

gaston@titine

gaston@titine 

Si sur la machine distante je vais cette fois à l'adresse localhost:8080, j'accède en réalité au port 10000 de ma machine locale.

Redirection globale via SOCKS

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

Un proxy SOCKS est un petit serveur utilisant un protocole conçu pour permettre à l'application qui sait en faire usage (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 :

gaston$ssh titine -D 3128

gaston@titine

gaston@titine 

Établissement d'un proxy SOCKS à partir de la machine distante sur le port local 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.

Limiter les droits à SSH

Présenté comme cela, si vous créer un utilisateur sur voir machine il va de-factor avoir accès à SSH, et donc à tout ce que cet outil permet. Cela va de la création du tunnel SSH, au lancement d'un shell distant, en passant, nous allons le voir un peu plus loin, la possibilité d'utiliser votre ligne Internet comme si c'était la sienne (mode "redirection"). Il n'est pas dit que vous y teniez... Voyons donc comment limiter cela.

Interdire l'accès root

Règle générale, 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.

Ne pas utiliser le port par défaut

Par défaut, le serveur utilise le port 22. Il est malin si l'on envisage de connecter se service au réseau public 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

configuration SSH cliente pour un port non standard

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.

Interdire l'accès root sans mot de passe

La 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 public. 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 public, 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.

Interdire l'accès à SSH complètement

Deux approches (au moins) sont possibles. La première consiste à créer un groupe, par exemple utilisateurs-ssh, et d'y ajouter les utilisateurs qui ont le droit d'accéder à SSH (quel qu'en soit l'usage, console ou tunnel).

Ceci fait, vous devez éditer votre fichier /etc/ssh/sshd_config pour ajouter la directive AllowGroups utilisateurs-ssh. Relancez le serveur et à partir de maintenant, seuls les membres du groupe utilisateurs-ssh pourront utiliser SSH.

gaston$ssh gaston@titine

gaston@titine's password:

Access denied.

gaston$ 

Interdiction de shell

Remarquez comme le SSH est vicieux, il va quant même demander un mot de passe alors qu'il sait déjà pertinemment que l'accès est interdit pour cet utilisateur

L'autre approche est de déconnecter le shell de l'utilisateur qui ne doit pas avoir accès à SSH. Cette méthode a ma préférence car elle est fonctionellement plus logique. Je ne cherche en réalité pas à interdire l'accès distant spécifiquement mais tout accès de type console ou tunnel.

Il suffit pour cela de modifier le fichier /etc/passwd et de remplacer le shell (la fin de la ligne, généralement à /bin/bash) par la commande /sbin/nologin. Le résultat sera le suivant :

gaston$ssh gaston@titine

gaston@titine's password:

── Bienvenue sur Titine !! ──

This account is currently not available.

Connection to titine closed.

gaston$ 

Interdiction de shell

Attention cependant, les techniques de modification du shell peuvent avoir de drôles d'effets de bords. Par exemple VSFTP utilise le shell courant pour ouvrir une session utilisateur via PAM. Or le /sbin/nologin, comme son équivalent moins loquasse /bin/false renvoient un code d'erreur indiquant un échec de connection qui empêcherait la session FTP de se former. La solution dans ce cas est de plutôt utiliser /bin/true.

Autre effet de bord, certains vérifient que le shell est valide dans le système et s'il ne l'est pas, refusent la connexion, même avec un /bin/true. La solution est d'ajouter /bin/true dans /etc/shells.

Interdire les redirections

Comme nous l'avons vu, SSH permet de créer des redirections de ports qu'il peut-être sage d'empêcher. Pour commencer, ce n'est pas la peine d'interdire cet usage si vous laissez un libre accès au shell. En effet, rien n'empêche un utilisateur de créer sa petite redirection à la main... Et si vous avez déconnecté le shell par un nologin ou équivalent l'utilisateur en question sera de toute façon bien en peine de tenter un tunnel vu que SSH va l'envoyer bouler faute de point d'atterrissage. Il reste cependant des cas, comme nous allons le voir plus loin, qui rend cela intéressant.

Vous pouvez donc globalement désactiver les redirections en ajoutant à /etc/ssh/sshd_config la directive AllowTcpForwarding No. Maintenant si vous désirez faire la même chose par utilisateur, c'est globalement beaucoup plus sport et passe obligatoirement par l'authentification par clef publiques/privées. Pas très pratique. Du coup c'est redirection pour tout le monde ou pour personne.

Autoriser l'accès au redirections mais pas au reste

Dans certains cas, nous aimerions bien que le shell ainsi que le lancement de commande en général soit interdits, sans pour autant bloquer les redirections qui sont utiles pour accéder de manière sécurisée à un service local (postgresql, mysql, subversion, etc.).

Pour cela nous allons utiliser non pas un nologin mais un faux shell qui ne fera rien d'autre que roupiller. Un tel shell est téléchargeable ici et il convient de le décompresser puis le compiler (make) et de le placer dans le dossier /sbin/sleepshell. Ensuite, nous pouvons tester :

gaston$ssh gaston@titine

gaston@titine's password:

── Bienvenue sur Titine !! ──

Connection: 88.111.222.33 57248 88.22.32.44 22

Client: 8.111.222.33 57248 22

Terminal: /dev/pts/1

******

<CTRL-C>

gaston$ 

Interdiction de shell

Comme vous le voyez, ce shell un peu spécial n'autorise rien du tout et permet donc de se connecter sur le serveur via SSH sans avoir la moindre possibilité d'obtenir un terminal.

Après il suffit, comme pour le nologin, de coller ce shell dans la bonne ligne du /etc/passwd et de l'ajouter dans /etc/shells.

Accepter seulement certaines commandes

Solution ultime s'il en est, interdire le shell et toutes les commandes qui ne sont pas explicitement désignées comme valides. Toujours en utilisant la technique du nologin, nous pouvons créer un script filtrant qui fera office de shell :

#!/bin/sh

# récupération de la ligne de commande complète
ligne=$2

# extraction de la commande
commande=${ligne%% *}

case "$commande" in
  # c'est une commande autorisée...
  "svnserve")
     $ligne
     ;;

  # tout le reste est interdit
  *)
        echo "Pas de $commande ($ligne) chez nous !!" > /dev/stderr
  ;;
esac

/sbin/restricted_shell

Ici nous interdisons tout sauf svnserve (le serveur de subversion). Le script en lui-même n'est pas sorcier, il s'agit juste de prendre le deuxième paramètre donnée par ssh (ce qu'il y a après le -c), d'extraire le premier mot et de le tester. Si c'est bon, on exécute la commande comme un bash l'aurait fait. Le cas échéant, une erreur est écrite sans pour autant renvoyer un code d'erreur, ce qui permet d'utiliser ce script comme un /bin/true.

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.