Connexion
Gitlab-CI, clé SSH avec passphrase, petit casse-tête
C’est un cas peu commun et qui m’a donné du fil à retordre (on parle de 3h d’essais/erreurs), c’est suffisamment barbu pour que je prenne la peine de partager l’info, en redonnant du contexte et un peu plus d’explications quand même.
Le contexte, donc
Nous sommes dans une migration de jobs qui s’exécutaient sur Jenkins à la main et qui doivent être refaits dans Gitlab-CI. Une grande partie de la facilité vient du fait que tout est basé sur Ansible, ce qui fait qu’on a finalement qu’à gérer « l’autour » de la logique des jobs, à savoir le setup de l’environnement d’exécution pour Ansible. Certains de ces jobs ciblent des serveurs sous Windows, d’autres sous Linux (Ansible fait ça très bien, via WinRM/Powershell pour Windows, SSH/Python pour Linux). Pour les Windows, un compte technique dans l’annuaire utilisé pour les environnements de préproduction fera le taf à la place de… variables utilisateurs/mots de passe fournies aux jobs à l’exécution. Pour les Linux, ça repose sur un compte dédié avec une clé SSH exploitée par Jenkins.
En temps normal personne se poserait de question, sauf que là, mon problème est que la clé est protégée par une phrase de passe, en anglais passphrase, et c’est particulièrement compliqué de travailler avec, au point que la plupart des gens recommandent de virer la phrase de la clé. Sauf que là, c’est hors de question, j’ai pas le droit d’y toucher. Au moins je peux la récupérer depuis un Vault Hashicorp privé. Et donc, mon premier symptôme, c’est ça :
debug1: Trying private key: /home/appuser/.ssh/id_rsa debug1: read_passphrase: can\'t open /dev/tty: No such device or address
SSH, ça s’automatise bien normalement, et puis…
Le fameux tty qu’on voit, c’est l’interface qui doit permettre à l’utilisateur d’interagir, et donc de saisir la passphrase au moment souhaité, à savoir quand il doit la présenter pour la connexion. On comprend donc le problème avec un pipeline Gitlab-CI: point de TTY. Et pas la peine d’y penser, le client SSH n’a aucune autre méthode directe pour accepter ladite phrase (c’est pas comme l’installation du SDK Android où on peux suffixer < yes pour répondre automatiquement aux questions d’acceptation des licences).
À force de chercher et de torturer mes termes de recherche, je finis par tomber sur cet article. Fait intéressant, il mentionne des options/variables d’Ansible pour manipuler justement les clés et éviter de fournir la phrase à chaque fois. Mais le problème, c’est que pour ansible_ssh_prompt, on doit indiquer l’intitulé de la question à laquelle on doit répondre par la passphrase et qu’il va devoir « capturer ». Question qui n’est jamais posée puisque pas de TTY pour ça. Ce n’est donc toujours pas exploitable, mais une réponse suivante sur la même page me mets sur la voie.
Cette ligne m’intrigue particulièrement:
- echo "$SSH_PRIVATE_KEY" |tr -d '\r' | DISPLAY=None SSH_ASKPASS=~/.ssh/tmp ssh-add -
La documentation d’ssh-add va répondre à mes questions:
DISPLAY, SSH_ASKPASS et SSH_ASKPASS_REQUIRE
Si ssh-add a besoin d'une phrase secrète, il la lira sur le terminal actif s'il a été lancé dans un terminal. Si ssh-add n'a aucun terminal associé alors que DISPLAY et SSH_ASKPASS sont défi‐
nies, il exécutera le programme spécifié par SSH_ASKPASS (par défaut « ssh-askpass ») et ouvrira une fenêtre X11 pour lire la phrase secrète. Cela s’avère particulièrement utile lors de l'appel
de ssh-add depuis un fichier .xsession ou un script similaire.
Je tente donc la solution, mais fait face à un nouveau message d’erreur:
ssh_askpass: exec(/home/appuser/.ssh/.print_ssh_password): Exec format error
Là, ça m’a pris beaucoup moins de temps, et la solution finale était tout près, il manque le shebang au script que je fournis (.print_ssh_password). Au passage, et contrairement à la majorité des posts que j’ai pu lire sur le sujet, j’utilise une base python-alpine pour le job et pas Debian/Ubuntu, ce n’est donc pas bash qui est aux commandes, et donc il faut adapter un chouia la séquence, mais ça a donné ça :
script: - echo "[SSH]Initialisation Clé" - | mkdir ~/.ssh && chmod 700 ~/.ssh echo -ne '#!/bin/sh\necho $passphrase' > ~/.ssh/.print_ssh_password chmod 700 ~/.ssh/.print_ssh_password eval $(ssh-agent) echo "$key" | tr -d '\r' | DISPLAY="None" SSH_ASKPASS=~/.ssh/.print_ssh_password ssh-add - - echo "[INFO] Ping du serveur" - ansible linux_server -m ping -i inventories/$ANSIBLE_INVENTORY -vvvvvv
Ouais, la brochette de v à la fin permet d’avoir le moindre bout de message d’erreur, franchement abusez-en pendant une telle opération c’est super pratique.
Donc, qu’est-ce qu’on a fait ? En amont, via Vault, on récupère la clé privée dans la variable key et sa passphrase dans la variable passphrase, rien de très original là-dedans. En passant, comme cette récupération se fait pendant l’exécution du job, job qui se lance dans un runner Kubernetes, il n’y a pas de stockage persistant de ces variables. On crée le dossier .ssh avec les bonnes permissions à la racine du dossier utilisateur de l’image, et on y place un petit script dont le seul rôle est d’afficher le contenu de la variable passphrase. On démarre le ssh-agent, puis on traite le contenu de la variable key (pour virer d’éventuels retours chariot à la Windows), avant de l’envoyer à ssh-add (le tiret à la fin permet de dire qu’on lui envoie la clé directement, sans passer par un fichier), à qui on précise les variables DISPLAY et SSH_ASKPASS pour éviter de chercher à poser la question à un humain, la réponse étant directement fournie par le script.
Le résultat est sans appel:
linux_server | SUCCESS => {
"ansible_facts": {
"discovered_python_interpreter": "/usr/bin/python"
},
"changed": false,
"invocation": {
"module_args": {
"data": "pong"
}
},
"ping": "pong"
}
« Ça serait pas arrivé avec Kubernetes »
C’est vrai quoi, une API finalement c’est mieux pour faire tout ça non ?
J’avais envie de troller un peu, mais plus sérieusement, étant donné qu’il y a aussi un annuaire pour gérer les connexions utilisateurs sous Linux, je suis surpris que la méthode repose sur ce genre de mécanisme avec un compte local et une clé SSH et pas un compte technique de la même nature que pour les Windows, ce qui aurait simplifié le processus tout en harmonisant les configurations.
En tout cas, j’étais soulagé et heureux d’avoir pu trouver la solution et continuer mes migrations. Et vous, vos connexions SSH dans Gitlab-CI, vous les gérez comment ?
