Warum beschwert sich Keychain, dass id_rsa.pub fehlt?

Warum beschwert sich Keychain, dass id_rsa.pub fehlt?

ich leseDieser Artikelzum Einrichten unbeaufsichtigter Backups in Duplicity.

Ich bin im Teil 7.2. SSH KeyCaching

Ich habe folgendes zu meinem Stamm hinzugefügt.bash_profile

keychain --clear id_rsa 
. /root/.keychain/www-sh

Der Artikelgibt an, dass der Schlüsselbund gestartet werden soll und dass ich an dieser Stelle nach meiner PASSPHRASE für meinen privaten Schlüssel (/root/.ssh/id_rsa) gefragt werden soll.

Ich erhalte hier nicht die erwarteten Ergebnisse. Obwohl der Schlüsselbund tatsächlich gestartet wird, werden an dieser Stelle einige Warnungen ausgegeben:

KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/
Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL

 * Found existing ssh-agent (2014)
 * ssh-agent: All identities removed.
 * Warning: /root/.ssh/id_rsa.pub missing; can't tell if /root/.ssh/id_rsa is loaded

root@www:~# 

Ich habe einige Erwähnungen hierzu gefunden inGentoo-Forenaber die Benutzer des Threads scheinen verwirrt zu sein, warum Keychain danach fragt, id_rsa.pubund ich habe mich gefragt, ob irgendjemand weiß, warum Keychain nach dem öffentlichen Schlüssel fragt.

Antwort1

Ich gebe zu, dass ich keine Ahnung von der Funktionsweise von Keychain habe, aber es ist völlig verständlich, dass ein lokaler SSH-Agent verärgert ist, wenn er keinen öffentlichen Schlüssel hat, der zu dem vorhandenen privaten Schlüssel passt.

Überlegen Sie, was passiert, wenn Sie sich zur Authentifizierung an einen Remote-Server wenden. Der Remote-Server weiß aus seiner authorized_keysDatei, dass er bereit ist, einen Client zu akzeptieren, der nachweisen kann, dass er den entsprechenden privaten Schlüssel zu jedem Eintrag darin hat. Aber wie fordert er diesen vom Client an? Er kann weder jeden privaten Schlüssel selbst noch irgendeine Eigenschaft davon angeben, weil er sie nicht hat; er kann nur die öffentlichen Schlüssel oder deren Fingerabdrücke vorlegen, die er akzeptieren wird.

Wenn der Client über einen dieser öffentlichen Schlüssel verfügt, kann er sofort den passenden privaten Schlüssel auswählen und eine Antwort senden, die der Server als korrekt akzeptiert. Was soll er tun, wenn er diese öffentlichen Schlüssel nicht hat? Nacheinander alle privaten Schlüssel in seinem Repertoire ausprobieren? Ein besseres Rezept für die unsichere Offenlegung von Informationen kann man sich kaum vorstellen; ein Black-Hat-Angreifer müsste nur einen Man-in-the-Middle-Angriff auf eine einzige neue Verbindung starten, um legitime Antworten von jedem Schlüssel in Ihrem Schlüsselbund zu erhalten.

Es ist möglich, dass Schlüsselpaare eine Art interne Nummerierung haben, aber das wäre völlig willkürlich und es wäre unklug, sich darauf zu verlassen. Es gibt keine garantierte interne Eigenschaft, die einen privaten und einen öffentlichen Schlüssel miteinander verbindet, da die Schlüssel in einem Schlüsselpaar nichts gemeinsam haben, außer dass einer (hoffentlich) die einzige Entität ist, die rückgängig machen kann, was der andere tut.

Nein. Die beste Möglichkeit für den Client, den richtigen privaten Schlüssel für die Verwendung bei einem bestimmten Server auszuwählen, besteht darin, über die passenden öffentlichen Schlüssel zu verfügen, die ihn bei der Schlüsselauswahl unterstützen.

Antwort2

Ich denke, keychaines versucht, sicherer zu sein als das Programm, für das es als Helfer dient ( ssh).

Ab meiner aktuellen Version von OpenSSH ist es möglich, einen privaten Schlüssel hinzuzufügen, ssh-agentohne ssh-adddie öffentliche Schlüsseldatei zu haben. Nachdem Sie dies getan haben, können Sie sehen, ob es erfolgreich war, da ssh-add -lauch der Name der privaten Schlüsseldatei aufgelistet wird. sshverwendet den zwischengespeicherten Schlüssel zum Herstellen einer Verbindung, auch wenn mehrere Identitäten verfügbar sind. Das abwechselnde Ausprobieren wird in der Dokumentation ausdrücklich erwähnt.

$ ssh -V
OpenSSH_7.2p2, OpenSSL 1.0.2g  1 Mar 2016
$ man ssh_config
...
     IdentityFile
      ...
             It is possible to have multiple identity files speci‐
             fied in configuration files; all these identities
             will be tried in sequence.  Multiple IdentityFile
             directives will add to the list of identities tried
             (this behaviour differs from that of other configura‐
             tion directives).
      ...

Ich denke, es ist am besten, die AddKeysToAgentOption zu verwenden ssh. Es wird nur beim ersten Mal in Ihrer Sitzung nach der Passphrase gefragt, wenn Sie ssh-agentverfügbar sind. In Ihrem .bashrckönnen Sie einfach hinzufügeneval $(keychain --eval --noask)

verwandte Informationen