Verwenden Sie einen bestimmten weitergeleiteten Schlüssel von SSH-Agent?

Nehmen wir an, ich habe einen Schlüssel für Github, zusammen mit anderen Schlüsseln. Ich habe meinem ssh-Agenten ssh-add -Lauf meinem Heimcomputer A viele Schlüssel hinzugefügt ( gibt viele Zeilen zurück). In meinem habe .ssh/configich festgelegt, welcher Schlüssel mit welchem Host verwendet werden soll, z

ssh -T -vvv git@github.com 2>&1 | grep Offering

gibt

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

Wie erwartet wird nur ein Schlüssel angeboten. Aber dann ssh-ing zu einem Host B mit ForwardAgent yesund Wiederholen des gleichen Befehls, bekomme ich

debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.linode2
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.helium
debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github

Das heißt, es versucht alle meine Schlüssel. Dies ist problematisch, da nur eine begrenzte Anzahl von Schlüsseln versucht werden kann, bevor die Server zurückkehren Too many authentication failures. Also habe ich versucht, die Bearbeitung .ssh/configauf Host B einzuschließen

Host github.com
  IdentityFile /Users/doxna/.ssh/id_rsa.github
  IdentitiesOnly yes

dann bekomme ich aber doch keine schlüsselopfer, sondern

debug2: key: /Users/doxna/.ssh/id_rsa.github ((nil))

was ich vermute, bedeutet, dass der Schlüssel nicht gefunden wurde (?) Und schließlich befindet sich der Schlüssel auf meinem Heimcomputer A, nicht auf Host B, also lautet die Frage, wie man auf Host B darauf verweist? Hoffe, ich habe es geschafft, die Frage zu erklären.

ssh ssh-agent

— danmichaelo
quelle

Antworten:

Du hast die richtige Idee. Der einzige Teil, den Sie vermissen, ist, dass die Datei, auf die von verwiesen wird, IdentityFileexistieren muss. Es muss keinen privaten Schlüssel enthalten, es reicht aus, nur den öffentlichen Schlüssel zur Verfügung zu haben.

Auf Host B können Sie den öffentlichen Schlüssel vom Agenten extrahieren, indem Sie Folgendes eingeben ssh-add -L | grep /Users/doxna/.ssh/id_rsa.github > ~/.ssh/id_rsa.github.pubund dann auf diese Datei verweisen~/.ssh/config

— Kasperd
quelle

FYI der Name des öffentlichen Schlüssels spielt keine Rolle. Je nach Inhalt wird der richtige Schlüssel aus dem Agenten ausgewählt.

— Akostadinov

@akostadinov Richtig. Wenn Sie sshauf eine öffentliche Schlüsseldatei ohne zugehörige private Schlüsseldatei verweisen , sollte diese nur den öffentlichen Schlüssel aus der Datei lesen und den Agenten den entsprechenden privaten Schlüssel zum Generieren der Signatur verwenden lassen.

— Kasperd

Dadurch wird Ihr Schlüssel effektiv auf Host B gespeichert! In der Antwort unten von @ mc0e finden Sie eine Lösung, bei der der Schlüssel nicht auf dem Server gespeichert wird.

— Pitt

@Pitt Nein, tut es nicht. Es wird nur der öffentliche Schlüssel gespeichert. Und das ist kein Problem, denn es wurde nie erwartet, dass der öffentliche Schlüssel geheim gehalten wird. Durch die Agentenweiterleitung kann der Host den Schlüssel verwenden, solange die Agentenweiterleitung aktiviert ist. Der Agent sendet den geheimen Schlüssel jedoch niemals an eine andere Stelle.

— Kasperd

@kasperd Sie benötigen keine tatsächliche Kopie des privaten Schlüssels, während Sie eine Live-Verbindung zu einem Benutzeragenten mit dem Schlüssel haben. Als root können Sie auf die Agentenverbindungen anderer angemeldeter Benutzer zugreifen.

— mc0e

Gute Antwort von @Kasperd, aber beachten Sie auch, dass Sie, wenn Host B kompromittiert ist oder Sie nicht allen vertrauen, die dort über Root-Rechte verfügen, weiterhin alle Ihre Schlüssel einem Missbrauch aussetzen, solange Sie angemeldet sind in auf diesem Host.

Ein besserer Ansatz könnte daher darin bestehen, den Zugriff nur auf die benötigten Schlüssel weiterzuleiten. Vielleicht versuchen Sie, ssh-agent-filterwelche in Debian / Ubuntu-Repositories oder von Github ist .

EDIT: Ich habe ließ sich auf ssh-identanstatt ssh-agent-filterfür Schlüssel selektiv weiterzuleiten, wenn es nicht so ist eine Erfahrung glatt wie man vielleicht hoffen.

— mc0e
quelle

Aus @ kasperds Kommentar zu seiner Antwort: "Das ist nicht der Fall. Es speichert nur den öffentlichen Schlüssel. Und das ist kein Problem, da nicht erwartet wurde, dass der öffentliche Schlüssel an erster Stelle geheim gehalten wird. Durch die Weiterleitung des Agenten erhält der Host Zugriff auf Verwenden Sie den Schlüssel, solange die Agentenweiterleitung aktiviert ist, aber der Agent wird den geheimen Schlüssel niemals irgendwohin senden. "

— Bdoserror

@Bdoserror Als Root können Sie die ssh-agent-Verbindung missbrauchen, während der zugehörige Benutzer angemeldet ist. Sie kopieren einfach die SSH_*Umgebungsvariablen und melden sich mit dem Schlüssel an der gewünschten Stelle an, obwohl Sie noch keine tatsächliche Kopie haben.

— mc0e

Zur Verdeutlichung: Diese Antwort ist in der Tat falsch - während das Missbrauchsszenario von mc0e real ist, hat es nichts mit dem Speichern des öffentlichen Schlüssels zu tun. Wenn der Zwischenhost kompromittiert ist, kann Ihre Agentenverbindung unabhängig davon zur Authentifizierung mit Ihrem privaten Schlüssel verwendet werden ob Sie den öffentlichen Schlüssel auf dem Zwischenhost speichern oder nicht. Ihr privater Schlüssel wird nicht kompromittiert, und das Speichern des öffentlichen Schlüssels wird es nicht einfacher machen, da jeder Angreifer, der eine Verbindung zum Agenten hat, ihn ohnehin nur nach den öffentlichen Schlüsseln fragen kann.

— Setzen Sie Monica

@ marc-lehmann hab nochmal gelesen was ich geschrieben habe. Wenn Sie Schlüssel weiterleiten, werden diese freigelegt. Sie können jedoch festlegen, welche Schlüssel weitergeleitet werden.

— mc0e

Ich gehe auf das ein, was Sie geschrieben haben - bitte sprechen Sie den Inhalt unserer Kommentare an, nicht die Person. Das Problem ist, dass Ihre Antwort einfach falsch ist, da sie beim Schreiben davon ausgeht, dass die Schlüssel an den Remote-Host "weitergeleitet" werden. So etwas passiert nicht und die Schlüssel selbst sind nicht sichtbar.

— Setzen Sie Monica