Connexion SSH avec gpg-agent

Dans l’épisode précédent, je décrivais comment j’avais créé mes clefs et sous-clefs et la façon dont j’avais exporté les sous-clefs sur une YubiKey. Place à une mise en application du côté de la connexion SSH entre un poste client et un serveur. J’utilise déjà le processus d’authentification par clef SSH pour me connecter sur mes machines serveurs, distantes géographiquement ou pas, virtuelles ou non. Le principe est donc d’utiliser la clef d’authentification pour se connecter en SSH aux machines.

On gagne en praticité, car une seule clef va nous permettre de nous connecter à chacune de nos machines une fois celles-ci configurées. Cela passe néanmoins par une configuration de la machine cliente pour utiliser gpg-agent en lieu et place de ssh-agent, chose qui n’est pas forcément aisée. Je vais décrire la configuration que j’ai mise en place, résultat de plusieurs échecs successifs avant d’arriver à quelque chose de fonctionnel et en sachant que j’utilise Xorg et I3 pour la partie affichage et interface.

Configuration côté serveur

La première étape consiste à récupérer les informations de la clef nécessaires à la configuration du serveur. Après avoir inséré notre YubiKey, nous exécutons donc la commande suivante :

$ ssh-add -L
ssh-rsa BFFEB3NzaC ... pdqsdfwX6m1 cardno:000123456789

Nous pouvons alors copier les informations renvoyées par cette commande et les insérer dans le fichier authorized_keys de notre serveur.

Configuration côté client

Le but est maintenant de remplacer ssh-agent par gpg-agent. Nous commençons donc par configurer ce dernier en éditant le fichier .gnupg/gpg-agent.conf :

enable-ssh-support 
pinentry-program /usr/bin/pinentry-curses 
max-cache-ttl 300 
default-cache-ttl 300

Dans le fichier .pam_environment, nous ajoutons les lignes suivantes :

SSH_AGENT_PID   DEFAULT= 
SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"

Et enfin dans .zshrc :

export GPG_TTY=$(tty) 
gpg-connect-agent updatestartuptty /bye >> /dev/null

Il me semble que cette configuration est suffisante pour obtenir quelque chose de fonctionnel. Sur mon poste, j’ai quelques déclarations supplémentaires du côté des fichiers .profile, .zprofile qui font doublon pour la déclaration de la variable GPG_TTY. Il devrait être possible de les supprimer sans risques.

Test unique

Pour réaliser un test unique, après configuration de gpg-agent et avant d’effectuer toutes les modifications ci-dessus et de tester la persistance au redémarrage, j’ai utilisé les commandes ci-dessous pour tester la connexion au serveur avec la clef d’authentification et vérifier cette première étape.

sudo killall gpg-agent
sudo killall ssh-agenteval $( gpg-agent --daemon --enable-ssh-support )

Nous pouvons alors essayer la connexion SSH vers notre serveur et retrouver la configuration utilisant ssh-agent après un simple redémarrage. L’utilisation de l’option -vvv étant particulièrement utile pour suivre les étapes de connexion et détecter d’éventuels problèmes.

ssh user@server -vvv

Conclusion

Avec cette configuration, je suis donc en mesure de me connecter à mes serveurs via SSH en utilisant ma clef d’authentification stockée sur ma YubiKey et le PIN associé à la clef. S’il est plutôt aisé de réaliser une première connexion réussie, la principale difficulté concerne la persistance de la configuration et le lancement correcte des composants à l’ouverture de la session; en particulier pour l’affichage de l’interface de saisi du PIN via pinentry-curses.

Sources

Using GnuPG (2.1) for SSH authentication
YubiKey for SSH, Login, 2FA, GPG and Git Signing

GnuPG, clefs, YubiKey : c’est parti

L’enchaînement  et le choix des commandes et des configurations qui vont suivre sont essentiellement extraites du blog de Simon Josefsson dans son article Offline GnuPG Master Key and Subkeys on Yubikey NEO Smartcard.

Après m’être documenté sur la génération de clefs, GnuPG et les possibilités  d’intégration au système, je me suis donc naturellement tourné vers la pratique et l’expérimentation. J’essaye ici d’en retracer les étapes, afin d’être en mesure de le reproduire au besoin.

Quelques points restent à améliorer et à solutionner, notamment l’absence dans les systèmes live testés (Kali Linux, Debian 9.5.0 et Parrot Security 4.2.2), du composant scdaemon permettant de communiquer avec la YubiKey et conduisant à l’échec de la commande gpg –card-edit.

Dernière petite note avant d’entrer dans le vif du sujet. Pourquoi une YubiKey (Neo) ? Tout simplement parce que j’avais fait l’acquisition de ce matériel il y a de cela quelques années, mais n’avais pas réussi à l’intégrer à mon utilisation quotidienne. Ce dispositif été donc tout indiqué pour servir de support de stockage à mes sous clefs.

Pour rappel, les opérations effectuées ci-dessous sont à réaliser sur une machine hors ligne et dans un système « Live ». Les plus soucieux de leur sécurité pourront aller jusqu’à utiliser un ordinateur dédié à cette tâche (un raspberry pi zéro peut-être ?).

Continuer la lecture de « GnuPG, clefs, YubiKey : c’est parti »

[Vidéo] P. Servigne & J. Blamont : Introduction au siècle des menaces

Lien vers la vidéo : P. Servigne & J. Blamont : Introduction au siècle des menaces .

Il est agréable de retrouver Jacques Blamont chez Thinkerview, cette fois en compagnie de Pablo Servigne, pour une discussion éclairante. Encore une fois, du contenu d’une grande qualité.

9’11 – J. Blamont : Il y a d’autres ressources naturelles qui sont encore plus menacées. Et naturellement, celle qui vient à l’esprit et qui va connaître une aggravation, c’est la ressource en eau. Si on considère déjà ce qui se passait dans les quelques dernières années, en ce qui concerne la quantité disponible d’eau dans le bassin méditerranéen, on s’aperçoit que les crises politiques ou militaires viennent des sécheresses, du problème de l’eau. On a commencé à partir de 1970 à pomper dans toutes les nappes phréatiques, y compris les nappes fossiles qui ne se renouvellent pas, et donc on atteint maintenant un niveau où la situation, puisqu’on a consommé notre capital, la situation va s’aggraver rapidement. Je prends un exemple: le Yémen. Le Yémen, il y a des conflits, il y a des choses très graves. Quelle est la situation de la nappe phréatique au Yémen ? Elle était à 10 mètres de profondeur en 1970. Aujourd’hui elle est à un kilomètre. Ça veut dire que maintenant il faut pomper et on est en présence d’ailleurs du sur-pompage, c’est-à-dire ce pompage vide la nappe phréatique. Hors le Yémen a aujourd’hui à peu près une vingtaine de million d’habitants et en 2050, ce sera 45. En 2050, vous aurez 45 [millions de] Yéménites, et à ce moment-là, il n’y aura plus d’eau. Si l’on essaye de quantifier ce phénomène, les spécialistes disent que la population est en état de stress hydrique, c’est-à-dire de stress dû à un manque d’eau en dessous de 2000 mètres cubes par an et par personne. Tous les pays du Maghreb, l’Égypte, le Yémen était tous en 2000 au niveau juste en dessous du stress hydrique. Et si maintenant on descend de 2000 à 1000 mètres cubes, on appelle ça l’état de pénurie. À ce moment-là, on s’aperçoit qu’en 2050, tous les états, l’ensemble de tous les états, y compris le Maghreb, y compris l’Égypte, seront en état de pénurie. Et je viens de vous dire que 1 000 mètres cubes c’est le niveau de la pénurie, le Yémen sera à 100. […] Et donc, ce qui se produit, c’est que les pénuries engendrent des conflits, des conflits politiques, etc. […] Les causes des conflits seront les véritables pénuries qu’on ne saura pas régler. Par exemple, je vais en Inde assez souvent, je vois des villes, comme Hyderabad, comme Madras, qui s’appelle maintenant Chennai, qui sont des villes qui sont passées de 500 000 à 5 millions d’habitants en 20 ans. Elles pompent d’une façon excessive dans la nappe phréatique locale et donc ces gens-là n’auront plus à boire dans une dizaine d’années.

Somme de contrôle sous Windows 7

En cas de besoin, il existe un utilitaire intégré à Windows permettant de calculer la somme de contrôle (hash checksum) d’un fichier. Dans un powershell, on pourra donc utiliser la commande suivante :

certUtil -hashfile cheminVersLeFichier [algorithme]

L’algorithme est à choisir parmi les valeurs suivantes :

MD2 MD4 MD5 SHA1 SHA256 SHA384 SHA512