Structure générale du fichier

Commençons par le commencement, c’est un fichier texte contenant sur chaque ligne le nom d’une option et sa valeur. Le fichier est séparés en blocs commençant par l’option Host, les directives de chaque bloc ne s’appliquant qu’aux hôtes qui correspondent au motif indiqué. Par exemple

Host *.math.utah.edu
User g-pdm

dit qu’à chaque fois que je me connecte à un hôte du domaine math.utah.edu, mon nom d’utilisateur est g-pdm. En clair, les deux lignes suivantes deviennent équivalentes :

$ scp foo sunset.math.utah.edu:
$ scp foo g-pdm@sunset.math.utah.edu:

Comme on le voit, les options de ssh-config sont utilisée par tous les outils de la suite, et pas seulement par la commande ssh.

Alias

Précisons que Host se réfère au nom d’hôte que vous saisissez sur la ligne de commande, qui peut être différent du nom d’hôte réel, lequel se spécifie alors avec HostName. Par exemple, la section suivante n’a d’autre but que de raccourcir mes lignes de commandes en ne tapant que le nom d’hôte au lieu du nom pleinement qualifié. (C’est de la flemme, oui, et alors ?)

Host thue
HostName thue.elzevir.fr

C’est aussi pratique pour les hôtes qui n’ont pas d’adresse IP publique. Par exemple j’ai chez moi une machine principale, et parfois mon laptop qui tourne et auquel je peux vouloir accéder depuis la fac. Pour cela, j’utilise les fonction NAT de ma « libreboîte » (qui porte assez mal son nom, mais passons), mais c’est pénible de devoir préciser à chaque fois le numéro de port. L’entrée suivant concernait mon ancien laptop (paix à son âme) :

Host siegel
HostName elzevir.fr
Port 12622
HostKeyAlias siegel.elzevir.fr
ForwardAgent yes

La directive Port se passe sans doute de commentaires, mais si on utilise qu’elle, on a vite des problèmes. En effet, l’hôte en question a la même adresse que thue, mais une clé publique de serveur SSH différente. Ceci provoque des avertissements à chaque fois, car le client vérifie que la clé présentée par le serveur coïncide avec celle enregistrée dans le fichier known_hosts. On peut désactiver cette vérification, mais ça ne me paraît pas très prudent. Une bonne solution est fournie par HostKeyAlias, qui permet de donner un nom arbitraire (et donc unique si on le veut) à l’entrée de cet hôte dans known_hosts.

Au passage, une directive que j’aime bien est HashKnownHosts no : c’est la valeur par défaut en général, mais dans Debian, c’est à yes. L’idée du yes est que les entrées de known_hosts fournissent à un éventuel intrus des informations. L’idée du no, c’est d’une part que vous pouvez lire le fichier et donc le maintenir (effacer les vieilles entrées inutiles, par exemple), et d’autre part que ça peut être une source d’info utile (ça m’a bien dépanné le jour où les DNS de mon FAI étaient en rade, d’avoir des IP d’hôtes auxquels je pouvais me connecter, par exemple).

Toujours en passant, j’ai un peu menti à la fin du dernier billet : en fait, ForwardAgent vaut no par défaut, et je le passe à yes individuellement par hôte.

Tunnels

La dernière directive que j’utilise est LocalForward, qui est l’équivalent de l’option -L en ligne de commande. C’est utile pour les tunnels qu’on établi souvent. Par exemple, pour me connecter à la fac, je dois passer par un sas : les serveurs internes ne sont pas accessibles directement de l’intérieur. C’est embêtant, mais on a plusieurs stratégies pour simplifier la chose. L’une passe par l’utilisation de ProxyCommand : je ne pratique pas, je n’en dirai donc rien. Celle que j’utilise est la suivante.

Host galois2
HostName 127.0.0.1
Port 1033

Host tunnels
HostName sas.math.jussieu.fr
LocalForward 1033 galois2.math.jussieu.fr:22

J’établis d’abord une redirection du port local 1033 vers le port 22 de la machine à laquelle je veux me connecter via le sas. Cette opération est à effectuer seulement une fois quand j’ouvre ma session (je fais ça en même temps que ssh-add via un alias shell) avec la ligne de commande ssh -Nf tunnels (-N dit de ne pas exécuter de commande distante (on veut juste rediriger les ports en fait) et -f de tourner en arrière-plan). Ensuite, je peux me connecter directement à galois2 en tapant juste ssh galois2.

Ligne de commande

Oui, le titre du billet est ssh_config(5) et pas ssh(1) ni scp(1), mais bon, voyons quand même trois options pratiques en ligne de commande. Le première est -o qui permet de spécifier sur la ligne de commande toute option disponible dans le fichier de configuration.

Une autre option que j’aime, spécifique à scp, est -l pour limiter la bande passante utilisée (pratique pour un téléchargement non urgent en tâche de fond, un cron de sauvegarde, etc.)

Enfin, une spécifique à ssh est -t, qui permet de forcer l’attribution d’un tty sur la machine distante, même quand on spécifie une commande distante. Exemple : je veux me connecter sur thue, mon serveur de fichiers, relié à ma chaîne hifi, pour y lancer mocp, un lecteur de musique en console. Essayons naïvement.

mpg@roth:~% ssh thue mocp
Error opening terminal: unknown.

L’option -t est faite précisément pour ça. Je l’utilise aussi pour me connecter à la fac en choisissant mon shell (on n’a pas le droit de changer son shell de login) : ssh -t galois1 'zsh -l' et hop !

1. Garder en cache une copie déchiffrée de votre clé privée ssh, pour vous éviter d’avoir à saisir constamment la passphrase.
2. Permettre de voyager facilement entre différentes machines : les demandes d’authentification sont retransmises à la machine initiale.

Mon propos ici n’est pas de faire un guide de l’usage normal de ssh-agent mais plutôt de montrer comment le détourner légèrement. L’usage prévu est que les processus fils de ssh-agent ou du shell où il a été lancé aient dans leur environnement une variable SSH_AUTH_SOCK pointant vers un socket Unix permettant de communiquer avec l’agent.

Il n’y a pas longtemps, j’ai voulu utiliser une connexion ssh dans le contexte d’un hook post-commit de Subversion. Il s’agit par exemple de pages web que je tiens sous contrôle de version, et dont je souhaite qu’à chaque commit elles soient mises à jour sur le serveur web (auquel j’ai accès par ssh). Ça tombe bien, je me connecte à mon serveur SVN par la méthode ssh+svn://, et en principe j’ai toujours un ssh-agent qui tourne sur la machine de départ. Problème, les hooks SVN démarrent avec un environnement essentiellement vide.

Il faut donc essayer de retrouver soi-même les informations de ssh-agent. Ce n’est pas très difficile, en fait l’accès au socket n’est protégé que par les permissions au niveau du système de fichiers. Les quelques lignes de Perl suivantes trouvent un socket ssh-agent actif s’il y en a un et positionnent la variable SSH_AUTH_SOCK pour permettre son utilisation facile par les fils du processus courant.

sub hack_ssh_agent {
    return if $ENV{'SSH_AUTH_SOCK'};
    $success = 0;
    opendir TMP, "/tmp";
    for my $dir (grep (/ssh-/, readdir TMP)) {
        opendir TEST, "/tmp/$dir";
        ($agent) = grep (/^agent/, readdir (TEST));
        closedir (TEST);
        $ENV{'SSH_AUTH_SOCK'} = "/tmp/$dir/$agent";
        print "Trying /tmp/$dir/$agent\n";
        $success = (system("ssh localhost true") == 0);
        last if $success;
    }
    closedir TMP;
    die "Pas moyen de trouver un ssh-agent.\n" unless $success;
}

Outre l’utilisation présentée, à savoir récupérer les informations permettant de se connecter à un ssh-agent depuis un processus qui n’en est pas un descendant, je pense que ces quelques lignes de code ont un intérêt pédagogique. Elles montrent qu’il est très facile pour root de récupérer les ssh-agent de tous les utilisateurs s’il le désire. (Notons quand même que ça ne lui donne pas accès à la clé déchiffrée de façon permanente, non plus : c’est déjà ça.)

En soi, ce n’est pas un grand problème de sécurité : si on a pas confiance en root, on est de toutes façons déjà dans… les problèmes jusqu’au cou. Par contre, j’ai un compte sur la machine d’un ami en qui j’ai en général toute confiance mais qui est souvent très blagueur en matière informatique. J’ai donc pris soin d’insérer ForwardAgent no dans mon ~/.ssh/config concernant sa machine.