En fait, dans ce cas là, c'est un peu différent. Tu arrives sur un serveur que tu ne connais pas, et qui ne te connais pas. Dans ce cas, ton client va essayer de présenter au serveur toutes les clefs publiques qu'il connaît (présentes dans ton ~/.ssh) pour voir s'il y en a une qui matche pour lancer l'authentification. Pour chacune de ces clefs, le serveur en extrait les informations disponibles et cherche des sources publiques qui exposent ces clefs pour te redonner les informations publiques qu'il a pu déduire de ce qu'il a trouvé (ton profil github, par exemple).
Donc, sauf si tu stockes tes clefs ailleurs, le fait que tu utilises des clefs différentes pour tes clefs GitHub/Gitlab et sur tes serveurs ne change rien à ce qui est démontré par ce site.
Un certain nombre de clés sont essayées par défaut :
debug1: Will attempt key: /home/user/.ssh/id_rsa RSA SHA256:Ct1TO[…]
debug1: Will attempt key: /home/user/.ssh/id_ecdsa
debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/user/.ssh/id_ed25519
debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/user/.ssh/id_xmss
[…]
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Trying private key: /home/user/.ssh/id_ed25519_sk
debug1: Trying private key: /home/user/.ssh/id_xmss
Plus celle que j'ai ajoutée dans mon ssh-agent. Les autres ne sont pas présentées. Donc ma clé nommée id_rsa_github_glandos.pub n’est jamais envoyée. Ou alors ssh -v me ment.
Comme il dit, il faudrait que la clef soit dans ton ~/.ssh/ ; est-ce le cas de ton id_rsa_github_glandos.pub ?
Ceci dit, la condition n'est pas suffisante car il ne peut pas savoir tout ce qui est clef utilisable ou pas (même en se basant sur l'extension on ne sait pas si c'est une vieille clef qui n'est plus utilisée mais pas supprimée par exemple.) Je pense que c'est juste les clefs par défaut pour chaque algo actif (et qui sont nommés id_$algo …mais mon hypothèse se heurte à l'étrange id_xmss que je ne connait pas) Je regarde le manpage plus tard.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Client GitHub et serveur à la fois ?
Posté par Glandos . Évalué à 2.
Ce genre d'article est très intéressant.
Mais quand je regarde ce que je fais, de manière complètement ingénue :
~/.ssh/configJe me demande du coup qui possède son serveur SSH publiquement accessible sur une machine qui fait aussi du push ?
[^] # Re: Client GitHub et serveur à la fois ?
Posté par aiolos . Évalué à 2.
En fait, dans ce cas là, c'est un peu différent. Tu arrives sur un serveur que tu ne connais pas, et qui ne te connais pas. Dans ce cas, ton client va essayer de présenter au serveur toutes les clefs publiques qu'il connaît (présentes dans ton ~/.ssh) pour voir s'il y en a une qui matche pour lancer l'authentification. Pour chacune de ces clefs, le serveur en extrait les informations disponibles et cherche des sources publiques qui exposent ces clefs pour te redonner les informations publiques qu'il a pu déduire de ce qu'il a trouvé (ton profil github, par exemple).
Donc, sauf si tu stockes tes clefs ailleurs, le fait que tu utilises des clefs différentes pour tes clefs GitHub/Gitlab et sur tes serveurs ne change rien à ce qui est démontré par ce site.
[^] # Re: Client GitHub et serveur à la fois ?
Posté par Glandos . Évalué à 2.
Un certain nombre de clés sont essayées par défaut :
Plus celle que j'ai ajoutée dans mon
ssh-agent. Les autres ne sont pas présentées. Donc ma clé nomméeid_rsa_github_glandos.pubn’est jamais envoyée. Ou alorsssh -vme ment.[^] # Re: Client GitHub et serveur à la fois ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Comme il dit, il faudrait que la clef soit dans ton
~/.ssh/; est-ce le cas de tonid_rsa_github_glandos.pub?Ceci dit, la condition n'est pas suffisante car il ne peut pas savoir tout ce qui est clef utilisable ou pas (même en se basant sur l'extension on ne sait pas si c'est une vieille clef qui n'est plus utilisée mais pas supprimée par exemple.) Je pense que c'est juste les clefs par défaut pour chaque algo actif (et qui sont nommés
id_$algo…mais mon hypothèse se heurte à l'étrangeid_xmssque je ne connait pas) Je regarde le manpage plus tard.“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Client GitHub et serveur à la fois ?
Posté par claudex . Évalué à 3.
c'est un algo existant https://datatracker.ietf.org/doc/html/draft-mu-curdle-ssh-xmss-00
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Client GitHub et serveur à la fois ?
Posté par claudex . Évalué à 3.
Et le début dans OpenSSH date de 2018 https://www.openssh.com/txt/release-7.7
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Client GitHub et serveur à la fois ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Excellent, je découvre (et j'imaginais tout autre chose à première vue…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Client GitHub et serveur à la fois ?
Posté par Glandos . Évalué à 2.
Oui, je ne range pas mes clés ailleurs. Mais en effet, il n'essaie que les clés
id_$algo. Les autres ne sont pas listées dans leWill attempt.Et moi, si je veux m'y retrouver, je les nomme ces clés, sinon, je ne sais pas du tout à qui je les ai filées.
[^] # Re: Client GitHub et serveur à la fois ?
Posté par Samuel (site web personnel) . Évalué à 2.
C'est ce qu'indique la doc. man ssh_config :
[^] # Re: Client GitHub et serveur à la fois ?
Posté par aiolos . Évalué à 3.
Au temps pour moi, j'étais persuadé que le client essaiyait toutes les clefs dans
.ssh. Merci pour les précisions.Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.