Ellendhel's Blog

Dès que l'on utilise SSH régulièrement et que l'on souhaite faciliter ses connexions et transferts de fichiers, il est intéressant d'utiliser ssh-agent qui remplacera les demandes de mot de passe par une authentification à base de clés publiques et privées (si le serveur auquel on se connecte le permet, bien sûr).

Le principe est de lancer ssh-agent en début de session, de lui indiquer quelles clés privées charger et fournir les passphrases correspondantes. Dès lors, toute connexion vers les serveurs disposant des clés publiques appairées se fera automatiquement.

Il existe déjà plusieurs solutions pour automatiser cela ; on trouvera une procédure sur le site de GitHub par exemple ou encore le plasmoid Easy SSH Connection qui repose sur KDE Wallet. Comme la variété est toujours bienvenue dans le domaine logiciel, j'ai repris un de mes anciens scripts pour l'intégrer à KDE. Le but est de charger ssh-agent, demander via une boîte de dialogue la passphrase de la clé SSH par défaut et de propager l'utilisation de l'agent dans les terminaux ouverts par la suite.

Cela repose sur un script launch-ssh-agent-KDE.sh à placer dans le répertoire ~/.kde/Autostart et qui sera exécuté lors de l'ouverture de session. Ce script fera appel à un autre script (ssh-askpass-KDE.sh) qui devra être placé dans le répertoire ~/bin. Enfin on modifiera son fichier ~/.profile pour ajouter ce répertoire à la variable $PATH et charger les informations correspondantes à ssh-agent.

Les opérations sont données en commentaires dans le script principal, que vous pouvez télécharger avec son compagnon dans le fichier ssh-agent-KDE.zip. Tout ceci est fourni en l'état, sans garantie, et que vous pouvez adapter et redistribuer selon vos besoins.

Aux personnes consultant ce blog, tous mes voeux pour cette année qui commence !

Concernant ce site, une mise à jour a été effectuée il y a quelques jours, proposant un aspect un peu attrayant, mais également d'autres changements moins visibles.

Et autant que mon temps libre le permet, d'autres améliorations devraient venir petit à petit, ainsi bien sûr que de nouveaux articles.

Suite à l'installation et l'utilisation régulière d'Unbound et dnssec-trigger sur mon portable, je me suis retrouvé avec le problème récurrent de "comment faire cohabiter toute la ménagerie de résolution de nom ?.

En effet à chaque connexion, Unbound se lance sur l'interface de boucle locale, le client DHCP récupère une liste de serveurs DNS à utiliser, et dnssec-trigger effectue des tests pour chacun de ces serveurs afin de vérifier s'ils sont DNSSEC-capables ou non, et dans ce cas comment se rabattre sur d'autres serveurs DNS "corrects" et accessibles, pour signifier à Unbound comment il doit travailler.

Tout ça à l'air bien compliqué. Une formulation simple serait "je veux aller sur tel site web, qui peut me donner l'adresse IP correspondante ?" en posant la question à trois personnes en même temps. Il faut organiser le dialogue entre tout le monde et définir une hiérarchie.

Premièrement, le client DHCP. Il faut le paramétrer pour qu'il ne modifie plus le fichier /etc/resolv.conf sans quoi il sciera la branche sur laquelle Unbound est assis (et accessoirement cela provoquera des erreurs car le fichier est protégé en écriture depuis qu'Unbound est installé).

Il faut donc modifier le fichier /etc/dhcpcd.conf et ajouter l'option resolv.conf pour la ligne de la directive "nohook" (en fin de fichier) : nohook lookup-hostname resolv.conf.

Deuxièmement, le client DHCP (suite). Le modification précédente est utile mais ne nous permet plus de savoir quels serveurs DNS sont proposés sur le réseau auquel on se connecte. Il faut donc récupérer cette liste et soit la transférer à dnssec-trigger, soit la conserver temporairement pour la transférer plus tard.

Cela nécessite un nouveau fichier "hook" pour dhcpcd. Les "hooks" sont des scripts lancés par le client (sauf configuration contraire) selon les évènements reçus (connexion, déconnexion, renouvellement de bail, ...). Ils doivent être nommés avec un préfixe numérique pour définir leur ordre d'exécution. Dans notre cas, le script sera nommé 25-dnssec-trigger et sera placé avec ses petits camarades dans le répertoire /lib/dhcpcd/dhcpcd-hooks/.

Troisièmement, lancer Unbound. Comme expliqué dans un précédent article, rien de compliqué : il faut modifier le script /etc/rc.d/rc.inet2 pour placer les instructions pour utiliser le script rc.unbound.

Enfin, lancer dnssec-trigger. Là encore, on utilisera un script nommé rc.dnssec-trigger qui sera aussi géré via rc.inet2, juste après la section pour Unbound.

Résumé des instructions :

- ajouter resolv.conf à la fin de la dernière ligne du fichier /etc/dhcpcd.conf

- placer le fichier 25-dnssec-trigger dans le répertoire /lib/dhcpcd/dhcpcd-hooks/

- ajouter le code pour les scripts rc.unbound et rc.dnssec-trigger dans le fichier /etc/rc.d/rc.inet2

- placer les fichiers rc.unbound et rc.dnssec-trigger dans /etc/rc.d/ et les rendre exécutables

Après cela, vous devriez pouvoir vous connecter en toute simplicité à quelque réseau que ce soit et bénéficier de DNSSEC si c'est possible.

Tous les fichiers correspondants sont disponibles ici même.

Comme je l'ai déjà présenté ici même, OpenSSH couplé à des enregistrements SSHFP dans le DNS permettent de faciliter l'authentification d'un serveur lors de la connexion initiale (on parle de modèle TOFU : Trust On First Use).

Or depuis la publication d'OpenSSH 5.7, un serveur peut maintenant se faire reconnaître via une signature ECDSA en plus des habituelles DSA et RSA. ECDSA est un algorithme cryptographique basé sur les courbes elliptiques (Elliptic Curve Digital Signature Algorithm), ce qui apporte une variété bienvenue dans les solutions mathématiques utilisées.

Et dans le cas qui nous concerne, un problème se pose : il n'est actuellement pas possible de générer un enregistrement DNS correspondant pour SSHFP.

La création des enregistrements RSA (type 1 dans l'exemple ci-dessous) et DSA (type 2) fonctionne fort bien, conformément à ce que prévoit le RFC 4255 :

$ ssh-keygen -r serveur.example.net
serveur.example.net IN SSHFP 1 1 4fc1c467a52ee19afec96fbed3b886aba6054cba
serveur.example.net IN SSHFP 2 1 5048f6f74fb7b1e04b0da2de08321ee4168ef77a

Mais si l'on demande la création pour ECDSA, on est coincé :

$ ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -r serveur.example.net
export_dns_rr: unsupported algorithm

Et pour cause, le RFC 4255 ne prévoit rien dans ce cas. Un RFC est en préparation pour pallier à cela, mais le chemin de validation n'est pas encore fini ("Adding new reservations requires IETF consensus").

Que faire donc ? Si lors d'une connexion le client SSH (version 5.7) recherche une clé, il regardera pour ECDSA par défaut :

$ ssh -o "VerifyHostKeyDNS ask" serveur.example.net
Error calculating host key fingerprint.
The authenticity of host 'serveur.example.net (192.168.1.2)' can't be established.
ECDSA key fingerprint is df:81:f3:5c:24:ec:dc:eb:4a:89:99:3d:47:a5:54:8b.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Il suffit alors de préciser que l'on vérifiera une clé RSA, comme à l'habitude, en attendant une norme définitive :

$ ssh -o "VerifyHostKeyDNS ask" -o "HostKeyAlgorithms=ssh-rsa" serveur.example.net
The authenticity of host 'serveur.example.net (192.168.1.2)' can't be established.
RSA key fingerprint is ee:15:6e:29:95:2c:f2:73:b8:e5:a6:13:95:8d:e4:9f.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Pour rendre les choses plus simples, les options pourront être placée dans le fichier ~/.ssh/config pour l'hôte auquel on se connecte.