Ich versuche im Wesentlichen Folgendes zu tun:
ssh [email protected] -t ssh bob2@test-vm
das oben genannte funktioniert einwandfrei, wenn ich es einfach in das Terminal eingebe, allerdings habe ich Schwierigkeiten, es über die SSH-Konfigurationsdatei zu replizieren.
Folgendes habe ich in der Konfigurationsdatei:
Host bastion
HostName 35.192.152.35
User bob2
Host test-vm
User bob2
FOrwardAgent yes
ProxyCommand ssh bastion nc %h %p 2> /dev/null
Es kommt jedoch zu einem Fehler mit der Meldung „Zugriff verweigert“, ungültige öffentliche Schlüsseldatei? Das Obige habe ich aus diesem Beitrag herausgefunden: https://unix.stackexchange.com/questions/124078/wie-man-per-ssh-auf-einen-Server-zugreift-mit-einem-anderen-Server-mit-dem-Schlüssel-vom-zweiten-Server
Irgendwie hat es bei dem Typen funktioniert, aber bei mir scheint es nicht zu funktionieren. Ich habe auch versucht, Agent-Weiterleitung und TCP-Weiterleitung in der sshd_chroot-Konfiguration auf allen Seiten (Ursprung, Bastion und Server) zuzulassen, aber das hat keinen Unterschied gemacht.
wenn ich die Identitätspfade zwangsweise spezifiziere:
Host bastion
HostName 35.192.152.35
User bob2
IdentityFile /Users/bob/.ssh/id_rsa
Host test-vm
User bob2
FOrwardAgent yes
ProxyCommand ssh bastion nc %h %p 2> /dev/null
IdentityFile /home/bob2/.ssh/id_ed25519
Dann kommt der gleiche Fehler und zusätzlich noch die Meldung, dass das Verzeichnis "/home/bob2/.ssh/id_ed25519" nicht gefunden werden konnte.
Hat jemand eine Idee?
Antwort1
Wenn Sie erst einmal verstanden haben, dass Bastionen dazu dienen, Netzwerk-Firewalls zu überwinden und nicht zum Speichern von Schlüsseln, können Sie dies in eine 2-Befehls-Lösung mit minimaler Konfiguration umwandeln.
Stellen Sie sicher, dass auf A, Ihrem lokalen Computer, ein SSH-Agent ausgeführt wird.
Führen Sie einen einmaligen Befehl an B aus, wobei B die folgende Konfiguration hat:
Host B
ForwardAgent yes
User proxyuser
Und führen Sie den folgenden Befehl aus:
$ ssh B ssh-add # and possibly a reference to a non-standard key
Zu diesem Zeitpunkt verfügt Ihr lokaler SSH-Agent über den Remote-Schlüssel in seinem Cache.
Anschließend klappt es auch ganz einfach mit einem -J
oder ProxyJump
zwei :C
Host C
User user
ProxyJump proxyuser@B
$ ssh C
Mit der kleinen Unannehmlichkeit eines zusätzlichen einmaligen Befehls können Sie meiner Meinung nach Ihre Konfiguration ziemlich vernünftig halten.
Sie könnten sich die Frage stellen, ob die Speicherung des Schlüssels auf der Bastion Ihnen wirklich zusätzliche Sicherheit bietet, wenn er ohnehin auf Ihrem lokalen Computer zwischengespeichert wird. Natürlich gibt es einen kleinen Vorteil vonnichtDer Schlüssel ist auf der Festplatte gespeichert. Wenn Ihr lokaler Computer jedoch gehackt wird, macht es keinen großen Unterschied, ob Sie eine Datei lesen oder mit einem SSH-Agenten kommunizieren, der mit Schlüsseln geladen ist.
Antwort2
Es scheint, dass Sie möchten, dass Ihre Konfiguration test-vm in Bastion nach Schlüsseln sucht. Daher schlage ich vor:
- Kopieren Sie die Schlüsseldatei in den .ssh-Ordner von bob2 in Bastion.
- hinzufügenProxy-Befehlmit ssh-add in Ihrer Konfiguration.
Antwort3
Das Folgende funktioniert bei mir ... Fast dasselbe wie bei Ihnen, außer dass ich die IP-Adresse des endgültigen Ziels angebe (in Ihrem Fall möglicherweise nicht relevant) undIch musste kopierender Schlüssel von der Bastion zu meinem lokalen Host, da meine ssh_config die Schlüsseldateien hier und nicht auf halbem Weg auf der Bastion findet:
==== added to .ssh/config ====
Host mybastion
HostName 133.35.41.9
User bastuser
IdentityFile /Users/bchapman/.ssh/bast_priv.key
Host mytarget
HostName 109.0.1.38
ProxyCommand ssh -q -W %h:%p mybastion
User targuser
IdentityFile /Users/bchapman/.ssh/targ_priv.key
==============
Danach kann ich problemlos ssh mytarget, scp localfile mytarget: usw. ausführen.