Pourquoi mes deux clés publiques SSH ont-elles le même début?

Je mettais à jour le fichier authorized_keys sur mon serveur avec la clé publique du nouvel ordinateur portable que j'ai obtenu et j'ai été surpris de découvrir que les deux clés publiques ont commencé de la même manière:

# key 1
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ....
#
# key 2
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ....

Quelle est l'histoire, AAAAB3...etc.? Avec certaines recherches en ligne, je vois que d'autres clés commencent également de la même manière. Cela explique-t-il l'algorithme ou la version ou quelque chose?

Il s'agit en fait d'un en-tête qui définit de quel type de clé il s'agit. Si vous consultez la section Algorithme de clé publique de la RFC 4253, nous pouvons voir que pour les clés RSA

Le format de clé "ssh-rsa" a l'encodage spécifique suivant:

 string    "ssh-rsa"
 mpint     e
 mpint     n

Ici, les paramètres «e» et «n» forment le blob de clé de signature.

En fait, si vous décodez en Base64 la chaîne "B3NzaC1yc2E", vous verrez qu'elle se traduit en ASCII par "ssh-rsa". Vraisemblablement, le "AAAA" représente une sorte d'en-tête afin que l'application puisse savoir où exactement dans le flux de données commencer le traitement de la clé.

Le format de clé publique SSH est documenté dans la RFC 4253 et résumé quelque peu ici . Les données codées PEM se composent d'un certain nombre de paires (longueur, données), et la première paire code le nom de l'algorithme, qui va être quelque chose comme ssh-rsaou ssh-dsa.

Cela signifie que la partie initiale des données de clé publique pour toutes les clés ssh va être similaire.

J'ai fait une plongée excessive dans le format après avoir suivi les liens de Scott pour les funsies. TLDR:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ...
       |  "ssh-rsa"   |exponent|   modulus

La RFC4231 spécifie les deux types de données utilisés:

• string: Chaîne binaire de longueur arbitraire. Les chaînes peuvent contenir des données binaires arbitraires, y compris des caractères nuls et des caractères 8 bits. Ils sont stockés comme uint32contenant sa longueur

• mpint: Représente plusieurs entiers de précision au format complément à deux, stockés sous forme de chaîne, 8 bits par octet, MSB en premier. [...]

RFC4253 sec 6.6 dit que la clé est codée comme suit :

Le format de clé "ssh-rsa" a l'encodage spécifique suivant:

string    "ssh-rsa"
mpint     e
mpint     n

Ici, les paramètres «e» et «n» forment le blob de clé de signature. [Ed: mais le blob semble également contenir la chaîne "ssh-rsa"...]

La signature résultante est codée comme suit:

string    "ssh-rsa"
string    rsa_signature_blob

La valeur de 'rsa_signature_blob' est codée comme une chaîne contenant s [Ed: ne sais pas ce qu'est s.] ( Qui est un entier, sans longueur ni remplissage, non signé et dans l'ordre des octets du réseau).

"ssh-rsa"

La chaîne ssh-rsaest convertie en \x00\x00\x00\x07ssh-rsa, qui l'encode ensuite AAAAB3NzaC1yc2E=, donc toutes les clés ssh-rsa doivent commencer par cela.

e, l'exposant public

Habituellement, quelque chose comme 3, 17, 257, 65537. Ces nombres sont encodés comme ci-dessous (avec le décalage de fin par rapport au dessus)

• 3 → '\x00\x00\x00\x01\x03'→AAAABAw
• 17 → '\x00\x00\x00\x01\x11'→AAAABEQ
• 257 → '\x00\x00\x00\x02\x01\x01'→AAAACAQE
• 65537 / 0x10001 → '\x00\x00\x00\x03\x01\x00\x01'→AAAADAQAB

Donc, si vous voyez "BAw", votre exposant était 3, ou "DAQAB" = 65537

n, le module (produit de vos deux nombres premiers secrets, factorisez cela!)

AAABAQaprès ce qui précède signifie que votre longueur de clé est de 2048 bits (et que votre exposant était comme DAQAB en raison du remplissage en base64). Le reste de la base64 est l'exposant, il n'y a rien après.

Autres préfixes de module qui peuvent être courants:

• AAAAg 1024 bits, e = 0x10001
• AAAQI: 2048 bits, e = 3