Einrichten der ssh-Konfigurationsdatei mit id_rsa über den Tunnel

Ich habe Probleme, eine gültige Konfiguration einzurichten, um eine Verbindung mit einem zweiten Computer herzustellen, einen anderen Computer zu durchlaufen und eine id_rsa (die mich nach einem Kennwort fragt) zu verwenden, um eine Verbindung mit dem dritten Computer herzustellen.

Ich habe diese Frage in einem anderen Forum gestellt, aber keine Antwort erhalten, die als sehr hilfreich angesehen werden könnte.

Das Problem, genauer beschrieben, lautet wie folgt:

Local machine: user1@localhost
Intermediary machine: user1@inter
Remote target: user2@final

Ich kann die gesamte Verbindung mit pseudo-tty herstellen:

ssh -t inter ssh user2@final

(Dies fragt mich nach dem Passwort für die id_rsa-Datei, die ich auf der Maschine "inter" habe.)

Um die Arbeit zu beschleunigen, möchte ich jedoch meine .ssh / config-Datei so einstellen, dass ich mich einfach mit folgendem Befehl mit der Maschine "final" verbinden kann:

ssh final

Was ich bisher habe - was nicht funktioniert - ist in meiner .ssh / config-Datei:

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Die Datei id_rsa wird verwendet, um eine Verbindung mit dem mittleren Computer herzustellen (hierfür muss kein Kennwort eingegeben werden), und die Datei id_rsa_2 wird verwendet, um eine Verbindung mit dem Computer "final" herzustellen (für diesen Computer wird ein Kennwort angefordert).

Ich habe versucht, einige LocalForwardund / oder RemoteForwardFelder zu mischen und die id_rsa-Dateien sowohl auf der ersten als auch auf der zweiten Maschine abzulegen, aber ohne jegliche Konfiguration konnte ich scheinbar keinen Erfolg haben.

PS: Der Thread, von dem ich versucht habe, Hilfe zu bekommen:

http://www.linuxquestions.org/questions/linux-general-1/proxycommand-on-ssh-config-file-4175433750/

— Rubens
quelle

Antworten:

METHODE 1 (benutze ssh-key auf inter)

Wenn Sie den Authentifizierungsablauf beibehalten möchten

local -- authenticate --> inter -- authenticate (ask password) --> final

Dies ist mit .ssh / config proxyhost nicht möglich.

Was Sie brauchen, ist ein Bash-Shell-Alias (ich hoffe, Sie verwenden Bash).

In ~/.bashrc, fügen Sie folgende Zeile

alias ssh-final='ssh -t inter ssh user2@final.com'

Geben Sie in der Eingabeaufforderung einfach Folgendes ein

ssh-final

finalAbschnitt in ~/.ssh/configwird nicht verwendet.

Verbindungsdetails (1)

ssh -t inter ssh user2@final.com kann wie folgt angezeigt werden

local# ssh inter
inter# ssh user2@final.com

localist nur "reden" mit inter. Es gibt keine direkte oder indirekte SSH-Verbindung zwischen localund final. localzeigt nur die Ausgabe von ssh user2@final.com.

METHODE 2 (benutze ssh-key auf local)

Authentifizierung mit demselben SSH-Schlüssel

Host inter
    User user1
    HostName inter.example.com

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Lokal kopieren ~/.ssh/id_ras.pubnach

/home/user1/.ssh/authorized_keys in `inter`
/home/user2/.ssh/authorized_keys in `final`

Verbindungsdetails (2)

SSH Tunneling

Bevor wir ins Detail gehen ProxyCommand, schauen wir uns das folgende Beispiel an

Schritt 1 im Terminalfenster 1

local# ssh inter -L 2000:final.com:22

Schritt 2 im Terminalfenster 2

local# ssh localhost -p 2000

In Terminal 1 wird ein Tunnel zwischen dem lokalen Port 2000 und dem final.com-Port 22 eingerichtet. Alles, was an den lokalen Port 2000 gesendet wird, wird an den final.com-Port 22 weitergeleitet und umgekehrt.

In Terminal 2 stellt ssh eine Verbindung zum lokalen Port 2000 her, kommuniziert jedoch tatsächlich mit final.com-Port 22, dem sshd.

Beim Tunneln wird der lokale ssh-Client in Schritt 2 direkt mit final.com sshd verbunden.

Die "Ausgabe" des lokalen Ports 2000 ist "roher" ssh-Daemon-Verkehr.

Die übliche Verwendung eines solchen Tunnels besteht darin, auf einen internen Webserver oder einen E-Mail-Server zuzugreifen. Das Folgende ist ein Beispiel für einen Webserver

local# ssh inter -L 2000:final.com:80

Verwenden Sie im Browser die folgende URL

http://localhost:2000

Die beiden Endpunkte des Tunnels sind der lokale Port 2000 und der final.com-Port 80.

Verkehr kommt in und aus dem Tunnelendpunkt "wie besehen". Nennen wir das "rohen" Verkehr.

ProxyCommand

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Das ProxyCommandgeht noch einen Schritt weiter. Es überspringt den Schritt des Erstellens eines lokalen Ports und stellt eine Verbindung zu diesem her.

Ein ssh-Client führt jeden Befehl aus, der dahinter steht ProxyCommand, und behandelt die Ausgabe dieses Befehls als "unformatierten" Datenverkehr. Es hält sich am lokalen Endpunkt fest und stellt dann eine SSH-Verbindung her.

Warum arbeitet einer den anderen nicht?

Der folgende Befehl

ssh inter nc final.com 22

Im Grunde bedeutet (1) Verbinden mit inter, dann (2) interAusführen des Befehls nc final.com 22.

nc - arbitrary TCP and UDP connections and listens

nc final.com 22Stellt also eine Verbindung zu final.com-Port 22 her, druckt den gesamten eingehenden Datenverkehr auf stdout aus und sendet den gesamten stdin auf die andere Seite. Es ist ein "Tunnel" zwischen nc stdin / out und final.com Port 22.

Da nces innerhalb der SSH-Sitzung ausgeführt wird, wird die gesamte Standardausgabe als "unformatierter" Datenverkehr an den SSH-Client zurückgegeben. Und der ssh-Client kann Datenverkehr an nc stdin weiterleiten, der dann an final.com-Port 22 endet.

Durch den obigen "Tunnel" startet der lokale ssh-Client eine ssh-Sitzung final.comdirekt mit.

Der folgende Befehl

ssh -t inter ssh user2@final.com

funktioniert nicht mit, ProxyCommandweil der aus ihm heraus nicht "roher" Verkehr von einem ssh-Dämon ist. Es ist die Standardausgabe eines SSH-Clients . Kundengespräch mit Kunden bedeutet kein Geschäft.

Authentifizierung mit verschiedenen SSH-Schlüsseln (OP Original Konfiguration)

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Lokal kopieren ~/.ssh/id_ras.pubnach

/home/user1/.ssh/authorized_keys in `inter`

Lokal kopieren ~/.ssh/id_ras_2.pubnach

/home/user2/.ssh/authorized_keys in `final`

Beides ermöglicht die folgende Verwendung

local# ssh final

Zusätzliche Prüfung

Verwenden Sie ausführlich

local# ssh -v final

Das sollte helfen, das SSH-Problem zu identifizieren.

Überprüfen Sie nc

ProxcyCommandwird ausgeführt ncam inter. Prüfen Sie, ob ncam tatsächlich verfügbar ist inter.

local# ssh inter
inter# nc final.com 22

Überprüfen Sie, ob der RSA-Schlüssel richtig eingerichtet ist

Wenn für interund andere Schlüssel verwendet werden sollen final, sollten folgende Dateien auf dem lokalen Computer vorhanden sein

local# ls ~/.ssh
id_rsa id_rsa_2 id_rsa.pub id_rsa_2.pub

Da Sie interbereits zu ssh können , überprüfen Sie das Schlüssel-Setup auf final. Von Ihrem lokalen Computer

local# ssh -t inter ssh user2@final
final# cat .ssh/authorized_keys

Sie sollten den Inhalt von id_rsa_2.pubdort sehen.

— John Siu
quelle

Entschuldigung, ich hätte darauf hinweisen sollen. Ich kann zwar eine Verbindung herstellen ssh -t, aber ich möchte genau das Verhalten simulieren, das ich habe, wenn ich ssh -tnur die Konfiguration auf der Website verwende .ssh/config.

— Rubens

Die Konfigurationsdatei, auch die, die Sie posten, sollte funktionieren. Versuchen Sie, den checkingSchritt durchzugehen. Es muss etwas fehlen / falsch sein.

— John Siu

Mit ssh -twird dein ssh to finalinitiiert inter, was "fast" das selbe ist wie local# ssh interdamals inter# ssh final. Die Authentifizierung erfolgt zwischen interund final. Mit proxy / nc wird Ihr ssh to final von Ihrem lokalen Rechner über einen Tunnel zu initiiert final. Die Authentifizierung erfolgt zwischen localund final.

— John Siu

@ Rubens basiert auf Ihrem Kommentar, ich denke, Sie irren sich, dass Sie immer noch interssh-key verwenden, um sich mit zu authentifizieren final. Versuchen Sie, id_rsa_2in local~ / .ssh / id_rsa_2 zu kopieren (lokale ID_rsa NICHT ÜBERSCHREIBEN), und Ihr Problem ist möglicherweise behoben.

— John Siu

Beachten Sie, dass ssh2 nceingebaut ist. ProxyCommand ssh gateway nc %h %pSie würden also statt schreiben ProxyCommand ssh inter -W %h:%p.

— user123444555621

Ich habe keine tatsächlich aufgelisteten Fehler oder ssh -v-Anweisungen gesehen, die helfen würden, festzustellen, wo es aufhängt.

Hey Mann, Sie haben es fast richtig gemacht - der beste und sicherste Weg ist, beide Schlüssel auf dem lokalen Rechner zu haben. Sie würden dann die Weiterleitung von ssh-agent verwenden, um eine Verbindung herzustellen, anstatt die Schlüssel in Zwischenschritten zu belassen. Sie haben auch den Vorteil, dass Sie Ihre Passphrase nur einmal pro Anmeldung eingeben müssen.

Wenn Sie ein modernes / benutzerfreundliches Betriebssystem wie Ubuntu (auf Ihrem lokalen Computer) haben, sollte dies ohne * Massieren * problemlos funktionieren. Ich habe die Identitätsdatei absichtlich weggelassen, Sie werden sie nicht brauchen.

Ihre Konfigurationsdatei würde folgendermaßen aussehen:

Host inter
    User user1
    ForwardAgent yes
    HostName inter.com

Host final
    ForwardAgent yes
    User user2
    HostName final.com
    ProxyCommand ssh inter nc %h %p

Wenn dies nicht der Fall ist, führen Sie die folgenden Schritte aus, um sicherzustellen, dass der ssh-agent ausgeführt wird:

'ssh-add -l' (lower case L) will list your private keys if any are loaded, or will be blank, or will say can’t connect to ssh-agent, if so, start ssh-agent.
'eval `ssh-agent`' (those are backticks) starts ssh agent
'ssh-add' will add your key… you can add a path argument if you have a key in a non-default area. At this point you will enter your passphrase.

Es gibt hier eine nette Anleitung, die erklärt, wie das funktioniert .

— MattPark
quelle