Le mpg-blog

Le précédent billet évoquait très brièvement l’existence du fichier ~/.ssh/config et la possibilité de s’en servir pour faire des trucs intéressants. Voyons donc quelques options intéressantes de ce fichier, intéressant étant défini comme « que j’utilise »…

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 !