Lassen Sie SSH Hostnamen aus der Konfiguration auflösen, wenn Sie ProxyCommand und den Netcat-Modus verwenden

Lassen Sie SSH Hostnamen aus der Konfiguration auflösen, wenn Sie ProxyCommand und den Netcat-Modus verwenden

Ich versuche, einige universelle Optionen für das Abweisen von SSH-Verbindungen einzurichten. Hier ist meine ~/.ssh/configDatei in Kurzform:

Host *%via
  ProxyCommand ssh gateway -W $(echo %h | cut -d%% -f1) %p

Host gateway
  HostName gateway.example.com
  User username
  ForwardAgent yes
  IdentityFile keypathg

Host target
  User username
  HostName target.example.com
  IdentityFile keypatht

Wenn ich *%viadie HostAliase verwende, erhalte ich:

% ssh -vvv target%via
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/myuser/.ssh/config
debug1: /Users/myuser/.ssh/config line 5: Applying options for *
debug1: /Users/myuser/.ssh/config line 12: Applying options for *%via
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/myuser/.ssh/tmp/target%via_22_myuser" does not exist
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -A gateway -W $(echo target%via | cut -d% -f1):22
debug1: permanently_drop_suid: 501
debug1: identity file /Users/myuser/.ssh/id_rsa type -1
debug1: identity file /Users/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/myuser/.ssh/id_dsa type -1
debug1: identity file /Users/myuser/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

Wenn ich jedoch

% ssh target.example.com%via

Ich habe den Zielserver erreicht, aber als falscher Benutzer und ohne Pubkey-Authentifizierung.

ICHdenkenMeine Frage an dieser Stelle ist, ob diese Bounce-Methode bei Verwendung ForwardAgentdurch meine gesamte SSH-Konfiguration/Umgebung geht oder nur durch die Schlüssel. Wenn es nur die Schlüssel sind, können die ersteren irgendwie genutzt werden?

Meine SSH-Version ist 5.9v1, Gateway ist 5.9v1 und Ziel ist 5.3p1. Ich glaube, es -Wwurde in 5.4 eingeführt, aber das sollte für die letzte Box in der Reihe keine Rolle spielen? Die Verwendung der älteren Schule ncscheint nicht anders zu sein.

Ich habe überprüft, dass ich manuell per SSH auf jedes Feld in der Zeile zugreifen kann. Dies zeigt an, dass die Hostnamen-Alias-Informationen nicht weitergegeben werden, da ich dies am Gateway nicht kann, ssh targetaber ich kann ssh target.example.com. Dies funktioniert mit Pubkey-Authentifizierung. Gateway und Ziel haben übrigens denselben Benutzernamen, weshalb dies funktioniert, wenn keine Konfiguration gepusht wird.

Wenn ForwardAgenteine ähnliche Konfiguration diese Informationen nicht pushen kann, was ist die vernünftigste Möglichkeit, dies zu umgehen, indem man eine .ssh/config-Datei mit diesen Informationen auf dem Gateway behält?

Antwort1

Wow, danke, dass Sie diese Frage gestellt haben. Ich finde es selten, dass jemand SSH voll ausnutzt, und diese Frage betrifft mehrere Bereiche.

Dies ist kein ProxyCommandProblem. Der ProxyCommandweist den lokalen SSH-Client einfach an, etwas vorbereitend zu tun, bevor er versucht, mit dem Remote-Client zu kommunizieren. Ja, in unserem Fall kommunizieren wir mit einer anderen SSH-Sitzung, aber diese Sitzung -Wnimmt einfach unsere Eingabe entgegen und leitet sie an eine andere Maschine weiter. Sie können sich diese vorbereitende SSH-Sitzung als völlig unabhängig vorstellen. Unvermeidliche Autoanalogie: Ihr Auto ist dasselbe Auto, unabhängig davon, ob Sie eine Fähre nehmen mussten, um von Punkt A nach Punkt B zu gelangen.

Das ist kein ForwardAgentProblem. ForwardAgentDer lokale Client stellt eine Funktion bereit, die lokale Schlüssel in der Umgebung der Remotesitzung verfügbar macht. Sie sind noch nicht über das Einrichten der Remotesitzung hinausgekommen.

Es ist ein .ssh/configFormatproblem. Beachten Sie die zweite und dritte Debug1-Zeile. Sie listen auf, welche Host-Strophen von Ihrem angewendet werden .ssh/config. Sie bemerken, dass das $ ssh target.example.com%viafunktioniert, aber mit falschem Benutzernamen und Schlüssel. Nun, die Strophe für Host targetwird nicht gelesen (was den richtigen Benutzernamen und die richtige Schlüsseldatei liefern würde). Welche Strophen werden verwendet? *und *%via.

Wie werden diese Optionen akzeptiert? Interessanterweise entspricht das Platzhalterzeichen Zeichenfolgen der Länge 0. Host target*entspricht target, target%via, target.example.comund target.example.com%via.

Und deshalb fragen Sie sich, ob es helfen würde, eine .ssh/configauf dem gatewayComputer einzurichten. Nein, das würde es nicht. Sie würde nie gelesen werden. Alles geschieht von unserem lokalen Computer aus.

Alles, was ich erklärt habe, beantwortet nur die Frage, warum $ ssh target.example.com%viaes nicht funktioniert.

Sie bevorzugen $ ssh target%via. Zu Recht, es ist bequemer. Die Kurzform schlägt fehl, weil als Hostname targetnicht gefunden wird; es wird nicht aufgelöst. Warum gibt ssh nicht aus: ssh: Could not resolve hostname target: Name or service not known? Weil das ProxyCommandbereits erfolgreich hergestellt wurde. Elemente einer SSH-Verbindung wurden aufgebaut, aber der Hostnamenfehler tritt dort auf, wo er nicht erwartet wird, und daher wird die allgemeinere Meldung ausgegeben. Ich würde dazu einen Fehlerbericht einreichen, um herauszufinden, wo die Debuginformationen verbessert werden könnten.

Abschließender Kommentar:

Mir gefällt die Host *%viaSyntax. Sie ist sauber und dennoch flexibel. Ich hatte sie schon einmal gesehen Host *+*und sie verwendet sowohl den ersten als auch den letzten Teil, %h(ost)um zu bestimmen, wohin man gehen soll. Aber es erfordert etwas mehr Mühe, das zu verstehen. Link:http://wiki.gentoo.org/wiki/SSH_jump_host

verwandte Informationen