ssh_config(5)
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 !