Pourquoi / comment SSH ne parvient-il pas à s'authentifier si la machine * client * a une clé publique erronée?

Sur clienthostj'ai un pub: priv keypair stocké sous ~/.ssh/fooet ~/.ssh/foo.pub, respectivement. Sur remotehostj'ai la pubkey correctement existante dans ~/.ssh/authorized_keystelle que je peux me connecter en utilisant -i ~/.ssh/foo.

La connexion est (bien sûr) ne dépend pas de l'existence de clienthost:~/.ssh/foo.pub: Si je renomme ~/.ssh/foo.pubà ~/.ssh/bar.pubrien ne change.

Mais si je modifie un caractère clienthost:~/.ssh/foo.pubafin qu'il ressemble toujours à une clé publique valide, mais ne correspond plus à la clé privée, je ne peux pas me connecter. Pourquoi pas?

Pourquoi / comment SSH s’intéresse-t-il si le complément de clé publique à la clé privée est intact - et pourquoi ${privkey}.puble chemin de recherche?

macos ssh

— Christopher DeMarco
source

.... Laissez-moi voir si je comprends bien votre question. Vous vous demandez pourquoi une paire de clés privée / publique ne fonctionne plus après avoir CHANGÉ la clé publique (pas le nom de fichier, mais le contenu de la clé publique), de sorte que la clé privée / privée ne corresponde plus à un résultat?

— Darius

En ce qui concerne la deuxième partie de votre question, pourquoi le chemin de recherche, ce lien peut répondre à votre requête.

— Darius

Correct: pourquoi SSH se soucie-t-il de l'existence d'une clé publique sur l'hôte client?

— Christopher DeMarco

Avez-vous reçu un message d'erreur? Lorsque j’ai essayé votre expérience (modification du contenu de mon id_rsa.pub), il s’agissait simplement de fournir un message d’erreur Key_Load_Public: Invalid Formatmais ne m’empêchait pas de me connecter à l’hôte distant.

— Darius

Mon Mac est OpenSSH_6.9p1, LibreSSL 2.1.8sous OS X 10.11.6.

— Christopher DeMarco

Ce comportement peut être déroutant, mais cela prend tout son sens. Prenons le cas d'utilisation le plus courant, lorsque la clé privée est cryptée et non stockée dans le fichier ssh-agent.

Dans ce cas d'utilisation, le client lit les deux clés (publiques et privées stockées dans des fichiers séparés), mais n'a pas besoin de vous demander la phrase secrète et ne décrypte pas la partie privée s'il ne sait pas que la clé est acceptée par le serveur.

Si vous modifiez la clé publique en un autre élément non accepté par le serveur, la deuxième étape de l'authentification n'est pas effectuée. En faisant cela, vous rompez la "paire" qui est nécessaire pour le faire fonctionner correctement.

— Jakuje
source