Pour être franc, je me suis toujours dit que ça devrait arriver plus souvent. Je sais pas si Github (et les autres forges public) comptent sur le fait que les clés vont changer par elles mêmes avec les nouveaux algos, mais garder la même clé privée pour un service trop longtemps, ça me rends un peu nerveux d'un point de vue exposition au risque (que ça soit un risque d'ordre cryptographique qu'un risque d'oublier le bordel que ç'est de changer tout).
Donc pour 99.999% des gens ce n'est pas bon (aucune vérification de SSHFP, donc en pratique question même si SSHFP est géré par GitHub), c'est bon que pour ceux qui changent l'option pour déjà checker.
(corrigez-moi vite si je me plante, je n'y connais rien sur ce point précis et conclue surtout sur ce que je comprend de la doc et dans le cas général des options que je connais bien mieux).
Oeuf et poule, je comprend que GitHub ne s'emmerde pas avec une configuration qui sera utilisée par 3 amateurs d'options, "ça coûterai pas grand chose" est à mettre en relation avec le nombre d'utilisateurs et pas forcément un bon ratio tant que la valeur par défaut n'est pas au minimum à "ask".
Le défault est "non", en effet. J'imagine qu'il y a des raisons de vie privée qui rentre en compte.
Ensuite, publier un enregistrement SSHFP automatiquement, ça ne me semble pas non plus un effort énorme si tu as une API pour ton DNS. Et contrairement à DNSSEC qui va tout foutre en l'air quand ça pete, le SSHFP ne va pas casser grand chose si ça casse.
# Vu
Posté par Jean Gabes (site web personnel) . Évalué à 3.
Vu sur les builds ce matin, ça a été l'occasion de rendre ça un peu plus robuste à ce genre de blague :p
[^] # Re: Vu
Posté par Misc (site web personnel) . Évalué à 6.
Pour être franc, je me suis toujours dit que ça devrait arriver plus souvent. Je sais pas si Github (et les autres forges public) comptent sur le fait que les clés vont changer par elles mêmes avec les nouveaux algos, mais garder la même clé privée pour un service trop longtemps, ça me rends un peu nerveux d'un point de vue exposition au risque (que ça soit un risque d'ordre cryptographique qu'un risque d'oublier le bordel que ç'est de changer tout).
C'est supporté depuis 2015, mais je ne connais personne qui le fait.
# Et sur HN
Posté par Misc (site web personnel) . Évalué à 4.
https://news.ycombinator.com/item?id=35285390
# Dans le DNS
Posté par Glandos . Évalué à 4.
Y a SSHFP. Oui ça sert à pas grand chose sans DNSSEC.
Mais ça leur coûterait pas grand-chose de créer ces enregistrements je crois.
[^] # Re: Dans le DNS
Posté par Misc (site web personnel) . Évalué à 3.
Sauf erreur de ma part, par défaut, ça change juste le message pour dire "c'est dans SSHFP", et il faut quand même dire oui.
Donc ça ne changerais pas grand chose pour github et/ou tout les clients ssh qui vont devoir quand même confirmer, avec ou sans DNSSec, à mon avis.
[^] # Re: Dans le DNS
Posté par Glandos . Évalué à 3.
https://manpages.debian.org/testing/openssh-client/ssh_config.5.en.html#VerifyHostKeyDNS
A priori, oui, c'est bon.
[^] # Re: Dans le DNS
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 24 mars 2023 à 20:37.
La partie importante est :
Donc pour 99.999% des gens ce n'est pas bon (aucune vérification de SSHFP, donc en pratique question même si SSHFP est géré par GitHub), c'est bon que pour ceux qui changent l'option pour déjà checker.
(corrigez-moi vite si je me plante, je n'y connais rien sur ce point précis et conclue surtout sur ce que je comprend de la doc et dans le cas général des options que je connais bien mieux).
Oeuf et poule, je comprend que GitHub ne s'emmerde pas avec une configuration qui sera utilisée par 3 amateurs d'options, "ça coûterai pas grand chose" est à mettre en relation avec le nombre d'utilisateurs et pas forcément un bon ratio tant que la valeur par défaut n'est pas au minimum à "ask".
[^] # Re: Dans le DNS
Posté par Misc (site web personnel) . Évalué à 3.
Le défault est "non", en effet. J'imagine qu'il y a des raisons de vie privée qui rentre en compte.
Ensuite, publier un enregistrement SSHFP automatiquement, ça ne me semble pas non plus un effort énorme si tu as une API pour ton DNS. Et contrairement à DNSSEC qui va tout foutre en l'air quand ça pete, le SSHFP ne va pas casser grand chose si ça casse.
Ensuite, je dit ça, mais je le fait pas non plus.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.