Qu'est-ce que ssh envoie exactement lors de la négociation des clés?

Lors de la spécification explicite du fichier d'identité à ssh:

ssh -i ./id_rsa ...

J'ai ces lignes dans la trace de débogage ssh:

debug1: Offering public key: ./id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply

Cela signifie-t-il que ssh-generated id_rsacontient également un exposant RSA public? id_rsale format semble être assez explicite car il contient la clé privée avec son bloc "BEGIN PRIVATE KEY", donc "offrir la clé publique" doit signifier autre chose que "envoyer la clé publique au serveur".

ÉDITER:

Pour clarifier, je veux savoir ce qui se passe exactement derrière la ligne "offrant la clé publique". Si le client détient plusieurs clés, elles seront toutes proposées au serveur une par une.

ssh

— Alex B
source

Pour ajouter à ce problème, il existe une méthode permettant au serveur de vérifier si nous avons obtenu une bonne clé avant le défi. Parce que j'avais déjà un serveur qui avait refusé notre clé avant même de la décrypter. L'erreur là où à cause du nom n'est pas bien spécifié.

— Gopoi

Réponses:

pour vous connecter à un serveur SSH et vous authentifier avec votre paire de clés publique / privée, vous devez d'abord partager votre clé publique avec le serveur.

cela se fait en copiant la clé publique de votre clé privée sur le serveur, et en l'ajoutant ~/ssh/authorized_keyssoit par copier / coller, en copiant id_rsa.pubsur ~/.ssh/authorized_keyssur le serveur ou avec cat id_rsa.pub >> ~/.ssh/authorized_keys, en l'ajoutant à la liste.

lorsque vous vous connectez, le serveur utilise votre clé publique pour signer un défi, et votre client utilise votre clé privée id_rsapour déchiffrer le défi, le rechiffrer avec la publique du serveur host keyet le renvoyer.

l'hôte vérifie que vous avez correctement déchiffré le défi, en déchiffrant votre réponse avec sa clé privée, et le client / hôte établit une connexion chiffrée, basée sur les données partagées, pas sur vos clés publiques / privées.

à AUCUN POINT dans l'échange est votre clé privée, ou la clé privée de l'hôte échangée ou révélée. votre clé publique EST stockée sur le serveur, mais c'est pourquoi il s'agit d'une clé PUBLIQUE.

— cpbills
source

Oui, tout va bien, mais cela se produit avant que le serveur n'identifie la clé publique avec laquelle chiffrer le défi. J'ai plusieurs clés et elles sont toutes "offertes" au serveur une par une. Qu'est-ce que cela implique exactement? Et oui, je réalise que la clé privée n'est pas vraiment envoyée, je devrais probablement supprimer complètement cette ligne de la question. : P

— Alex B

lorsque vous spécifiez, ssh -i keynamevous dites à votre client ssh exactement quelle clé vous prévoyez d'utiliser pour vous connecter au serveur. si vous avez une douzaine de clés dans ~/.ssh/votre client, il ne parcourra PAS chaque clé. il recherchera ~/.ssh/id_rsa, ~/.ssh/id_dsaéventuellement , quelques autres noms de fichiers qui sont codés dans le client, ou quelle clé est spécifiée pour cet hôte dans ~/.ssh/config... short story short; votre client ne fournit / aucune clé / au serveur.

— cpbills

lorsque vous vous connectez, votre / client / déchiffre le défi à partir du serveur, puis tombe dans sa liste de clés privées locales standardisées pour chiffrer le défi, pour envoyer la réponse. Si la réponse au défi échoue, il / peut / passer au nom de clé suivant codé en dur, rechiffrez avec / cette / clé privée et réessayez. encore une fois, vos clés, publiques et privées ne sont pas / partagées / avec le serveur lors de l'authentification de connexion.

— cpbills

oh, j'ai relu ton commentaire; hôte: chiffre le défi avec la clé d'hôte, client: déchiffre le défi avec la clé de pub de l'hôte, client: chiffre le défi avec la clé privée, l'hôte: tente de déchiffrer le défi avec toutes les clés publiques répertoriées dans ~/.ssh/authorized_keysl'hôte sait ce qu'est le défi et ce qu'il cherche car une fois qu'une clé publique la déverrouille, elle sait utiliser cette clé.

— cpbills

@cpbills, désolé d'avoir oublié de mentionner que j'ai quelques clés d'un agent transféré, donc plusieurs clés sont proposées (le journal -vvv montre toutes celles-ci, même si je spécifie le fichier d'identité).

— Alex B

La cryptographie à clé publique / privée est basée sur un système très simple:

Vous disposez d'une clé publique capable de faire un chiffrement unidirectionnel et d'une clé privée qui est capable de déchiffrer. La clé publique peut alors être donnée à tout le monde dans le monde, et personne ne pourra décrypter vos données cryptées, bien qu'ils puissent crypter les données que vous pouvez décrypter avec votre clé privée.

La réponse à votre question est donc "votre clé publique".

— Satanicpuppy
source

Oui, merci, je sais en détail comment fonctionne la cryptographie à clé publique, mais je veux connaître les spécificités du protocole SSH et le format de la clé. Je souhaite savoir s'il stocke l'exposant public dans le fichier de clé privée, ou non? Pour tout ce que je sais, «offrir une clé publique» peut également signifier signer un nonce avec votre clé privée, afin que le serveur puisse trouver une clé publique correspondante.

— Alex B

Oui. il ne ssh-keygen -y vous donnera la clé publique de la clé privée, l'inverse ne fonctionne pas

— Mâtt Frëëman

Je ne pense pas qu'il devrait réellement envoyer la clé publique ou privée pour le moment. Un chiffrement doit être effectué par le client à l'aide de la clé privée sur un texte en clair déjà connu du serveur. L'hôte peut déchiffrer ce message à l'aide de la clé publique, sachant que le seul qui aurait pu le chiffrer correctement est un client qui détient la clé privée correspondante, authentifiant ainsi le client.

Je crois que cela dit Offering public key: ./id_rsaparce qu'il utilise la clé privée (stockée dans ./id_rsa) pour effectuer un cryptage sur le texte brut connu du serveur, puis le serveur utilisera la clé publique pour décrypter ce texte chiffré et confirmer qu'il correspond au texte en clair. Le fichier de clé publique ./id_rsa.pubne devrait jamais être nécessaire au client après la génération de clé initiale. Ceci n'est utilisé que par le serveur pour le déchiffrement.

— Trey Hunner
source

Je soupçonnais que quelque chose comme ça se produisait, mais je voulais quelques détails (c'est-à-dire le protocole de négociation de clé SSH réel). Je ne sais pas pourquoi vous avez voté contre.

— Alex B

Désolé ma réponse était si vague. Je ne connais pas les spécificités de la négociation de clés SSH, seulement les négociations générales nécessaires à l'authentification par clé publique. J'aurais peut-être été rejeté pour la réponse non spécifique.

— Trey Hunner