Autour de SSH

Depuis que j’ai commencé mon nouveau boulot, j’ai bricolé des trucs mais je suis bien incapable de reconnaître si c’est bien ou cruellement mauvais. Pour rappel je suis autodidacte, il est parfois difficile de savoir quand on suit une mauvaise voie alors je partage avec vous

Complétion SSH

On tape ssh luig, on appuie sur Tab, la complétion affiche alors ssh luigi.pizza.net.

Dans mon ~/.bashrc, j’ai complete -W "$(<~/.ssh/hosts)" scp ssh sshfsu qui me permet d’avoir la complétion pour scp, ssh et ma fonction sshfsu. Le fichier hosts n’est pas un fichier système, c’est moi qui le maintiens avec une liste des serveurs sur lesquels je me connecte. Ça marche parfaitement, rien à dire, je ne peux plus m’en passer. J’ai vu que certains parsent le fichier ~/.ssh/know_hosts. Sur Ubuntu par défaut le nom des hosts est hashé . On peut via une option SSH afficher en clair le nom des hosts dans know_hosts mais c’est déconseillé, ça abaisse la sécurité. Je vous renvoie vers l’article Sécuriser son fichier SSH known_hosts.

D’autres parsent le fichier ~/.ssh/config, je crois que c’est la solution que j’ai vu la plus souvent revenir. En ce qui me concerne, ça ne s’applique pas bien à mon utilisation. J’utilise une “bête” liste contenant plus de 200 serveurs. L’avantage c’est que c’est clair, simple, rien à parser. L’inconvénient, aucune automatisation. Je récupère la liste des serveurs de mon entreprise et l’envoie dans ~/.ssh/hosts via un script mais je parle d’automatisation directement avec SSH. Se baser sur ~/.ssh/know_hosts était clairement le bon plan. Le fichier se met à jour dès qu’on se connecte à un serveur et on l’a alors en complétion. Remarquons tout de même qu’à l’heure d’aujourd’hui où il n’est plus rare de jongler avec des centaines de conteneurs et serveurs, il peut être pertinent d’avoir déjà une liste bien remplie plutôt que la remplir au fil de l’eau en se connectant sur chaque serveur.

Comment procédez-vous de votre côté ? Pour Zsh, ça m’intéresse également.

ssh-agent

Wikipédia explique bien le concept de ssh-agent. Le but principal est d’éviter de retaper la phrase secrète de notre clé SSH privée 30 fois si on se connecte à 30 serveurs (je simplifie). Pour la majorité des distribs l’agent est chargé au lancement de la session graphique. Je suis sur Xubuntu et dans /etc/X11/Xsession.options, j’ai une option use-ssh-agent.

Il y a 247 manières de gérer le ssh-agent : manuellement, des fonctions dans ~/.bashrc, un service systemd (voir ArchWiki), j’ai retenu pour ma part Keychain (GitHub). C’est le plus simple je trouve, ça s’occupe de tout, ça gère SSH et GPG enfin je n’ai pas retesté depuis mais c’était le seul à ne pas me redemander ma phrase secrète lorsque j’ouvrais un nouvel onglet sur Terminator.

apt install keychainsed -i '/use-ssh-agent/s/^/#/' /etc/X11/Xsession.options # On commente la ligne use-ssh-agent sinon on a des messages d'erreurseval $(keychain --eval --quiet id_ed25519) # À placer dans ~/.bashrc

La prochaine fois que vous ouvrirez un terminal, il vous demandera votre phrase secrète puis terminé. Je vous renvoie vers l’article de Qanuq très complet sur keychain. Puisqu’on parle de ssh-agent je recommande chaudement l’article de Aeris sur ssh-agent + agent-forward.

Fonctions SSHFS

Au début j’avais appelé cette fonction sshfsup puis j’ai changé son nom en sshfsu, elle est à placer typiquement dans ~/.bashrc. Elle me permet de monter aisément un serveur via SSHFS : sshfsu server1.blog-libre.org. À noter que j’ai activé la complétion pour cette fonction. Vous pouvez remplacer /var par ce que vous voulez évidemment genre ~/, / etc. Merci de ne pas me souffler dans les commentaires “oh la la c’est pas très très bien/pro”, j’en ai besoin et le but est de partager, ça peut servir à d’autres dans un contexte non professionnel.

sshfsu() {cd && mkdir -p ${1%%.*}; sshfs cascador@$1:/var ${1%%.*}; (caja ${1%%.*} &> /dev/null &)}

J’utilise le Parameter Expansion de Bash, $1 c’est donc server1.blog-libre.org, ${1%%.*} devient donc server1.
cd && mkdir -p ${1%%.*} : Je me place dans ~/ puis crée le dossier server1
sshfs cascador@$1:/var ${1%%.*} : Je monte le serveur via SSHFS
(caja ${1%%.*} &> /dev/null &) : J’ouvre le dossier server1 dans le navigateur de fichiers (caja). A noter que j’aurais pu utiliser xdg-open à la place de caja ainsi ça aurait été le navigateur de fichiers par défaut qui aurait été utilisé, c’est ce que je vous recommande d’ailleurs

La fonction sshfsd (sshfsdown) me permet de démonter tous les montages SSHFS d’un coup (en général je n’en ai qu’un). Simple, efficace et élégante. Quelqu’un a mieux ?

sshfsd() {mount -t fuse.sshfs | awk '{system("fusermount -u " $3 " && rmdir " $3)}'}

mount -t fuse.sshfs : Je liste les montages dont le type de système de fichiers est SSHFS
awk '{system("fusermount -u " $3 " && rmdir " $3)}' : Grâce à awk (voir Input/Output Functions pour system) on prend la 3ème colonne qui correspond au point de montage (avec l’exemple de sshfsu, ça donnera /home/cascador/server1) puis on démonte fusermount -u et on supprime le dossier rmdir

Autres liens intéressants

Je vous invite à consulter les articles de la marque OpenSSH sur le Jdh et vous recommande particulièrement celui de Arnaud et Guillaume. Je vous rappelle également mes articles sur l’option Match de sshd_config et sur le bien utile sshrc.

Je n’ai pas parlé de ~/.ssh/config si je le fais ce sera dans un autre article, celui-ci étant déjà costaud.

Tcho !