Si je perds ma sous-clé, je me retrouve coincé dehors.
C’est pour ça que générer les sous-clefs (particulièrement la sous-clef d’authentification) directement sur la carte n’est pas forcément une bonne idée à mon avis, puisqu’il n’y a aucune sauvegarde possible.
Ce sera ma prochaine étape d'investigation mais saurais-tu si l'on peut renseigner la clé primaire et autoriser toutes sous-clés d'authentification valides liées à celle-ci ?
Pas à ma connaissance, et je doute que ce soit possible en l’état.
Il faut bien voir que le démon SSH, en face, ne voit rien d’autre qu’une clef SSH tout ce qu’il y a de plus habituelle. Il n’a aucune prise en charge pour OpenPGP, et les notions de clefs primaires et de sous-clefs (qui sont propres à OpenPGP) lui sont donc totalement étrangères.
Il est peut-être possible de faire quelque chose d’approchant avec Monkeysphere, mais
ça ne fonctionne plus avec n’importe quel serveur SSH (il faut obligatoirement Monkeysphere sur le serveur) ;
je n’ai jamais essayé.
Une autre approche serait d’utiliser des certificats SSH : tu génères une clef SSH servant d’autorité de certification, et tu l’utilises pour signer les clefs d’authentification. Sur le serveur, tu peux dès lors ne mettre dans le fichier ~/.ssh/authorized_keys que la clef publique de l’autorité de certification, et toutes les clefs signées par celle-ci seront acceptées (supprimant ainsi la nécessité de mettre à jour le fichier ~/.ssh/authorized_keys à chaque changement de clef). Idéalement, la clef de signature sera stockée sur un support hors-ligne dont tu ne la sors qu’au moment de signer une nouvelle clef (et tu feras ça sur une machine « air-gappée »).
L’avantage de cette approche est qu’elle ne nécessite pas de modification côté serveur (les certificats SSH, comme leur nom le laisse supposer, sont pris en charge nativement par OpenSSH). L’inconvénient dans le cas présent est qu’à ma connaissance, c’est l’agent GnuPG qui ne les gère pas — donc ce n’est pas utilisable, en l’état, avec une clef d’authentification stockée sur carte OpenPGP...
[^] # Re: Compléments
Posté par gouttegd . En réponse au journal GnuPG et authentification SSH. Évalué à 4.
C’est pour ça que générer les sous-clefs (particulièrement la sous-clef d’authentification) directement sur la carte n’est pas forcément une bonne idée à mon avis, puisqu’il n’y a aucune sauvegarde possible.
Pas à ma connaissance, et je doute que ce soit possible en l’état.
Il faut bien voir que le démon SSH, en face, ne voit rien d’autre qu’une clef SSH tout ce qu’il y a de plus habituelle. Il n’a aucune prise en charge pour OpenPGP, et les notions de clefs primaires et de sous-clefs (qui sont propres à OpenPGP) lui sont donc totalement étrangères.
Il est peut-être possible de faire quelque chose d’approchant avec Monkeysphere, mais
Une autre approche serait d’utiliser des certificats SSH : tu génères une clef SSH servant d’autorité de certification, et tu l’utilises pour signer les clefs d’authentification. Sur le serveur, tu peux dès lors ne mettre dans le fichier
~/.ssh/authorized_keysque la clef publique de l’autorité de certification, et toutes les clefs signées par celle-ci seront acceptées (supprimant ainsi la nécessité de mettre à jour le fichier~/.ssh/authorized_keysà chaque changement de clef). Idéalement, la clef de signature sera stockée sur un support hors-ligne dont tu ne la sors qu’au moment de signer une nouvelle clef (et tu feras ça sur une machine « air-gappée »).L’avantage de cette approche est qu’elle ne nécessite pas de modification côté serveur (les certificats SSH, comme leur nom le laisse supposer, sont pris en charge nativement par OpenSSH). L’inconvénient dans le cas présent est qu’à ma connaissance, c’est l’agent GnuPG qui ne les gère pas — donc ce n’est pas utilisable, en l’état, avec une clef d’authentification stockée sur carte OpenPGP...