Forum: PC Hard- und Software SSH Reverse Tunnel funktioniert nicht


von Rolf F. (Firma: G.) (benutzername0)


Lesenswert?

Ich habe versucht einen SSH reverse Tunnel einzurichten, aber das 
funktioniert nicht:

Es funktioniert das passwortlose SSH und Tunnel-Aufbau:

  ssh -R 2210:localhost:22 abc@123.stratoserver.net

oder auch

  /usr/bin/autossh -R 1999:localhost:22 abc@123.stratoserver.net


Aber das Verbinden funktioniert nicht:

  ssh localhost -p 1999

Dazu kommt eine Passwortabfrage, zu der immer gemeldet wird "Permission 
denied (publickey,password)", obwohl das Passwort immer richtig 
eingegeben ist.

Dabei habe ich auch in der sshd_config

  GatewayPorts yes

und

  GatewayPorts clientspecified

ausprobiert, anschließend "/etc/init.d/ssh reload".

Nach netstat ist der Tunnel vorhanden:

> netstat -ntl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address 
State
tcp        0      0 0.0.0.0:22              0.0.0.0:* 
LISTEN
tcp        0      0 0.0.0.0:2210            0.0.0.0:* 
LISTEN
tcp6       0      0 :::22                   :::* 
LISTEN
tcp6       0      0 :::2210                 :::* 
LISTEN

Aber wieso kann ich das Tunnelende nicht erreichen?

von Kriechstrecke (Gast)


Lesenswert?

> Aber wieso kann ich das Tunnelende nicht erreichen?

Kannst du wenigstens das Licht sehen?

von Rene H. (Gast)


Lesenswert?

Ein Keyfile hast Du angelegt?

von Rolf F. (Firma: G.) (benutzername0)


Lesenswert?

Rene H. schrieb:
> Ein Keyfile hast Du angelegt?

Ja, mit ssh-copy-id. Damit funktioniert passwortloses SSH.

von Rolf F. (Firma: G.) (benutzername0)


Lesenswert?

Ich habe nun herausgefunden wieso es nicht funktionert und auch wieso 95 
% aller Anleitungen zu Reverse SSH Tunnel schlicht falsch sind weil sie 
nicht funktionieren: Das

  ssh localhost -p 1999

auf dem Server macht, im Gegensatz zur Angabe der Passwortabfrage, den 
Login nicht auf dem localhost (Server) sondern auf dem Client hinter dem 
SSH-Server. Das localhost ist nämlich durch den Tunnel nicht der Server 
sondern der Client dahinter!

Das Login kann daher mit dieser Kommandozeile nur funktionieren wenn man 
a) auf dem Server wie auf dem Client dahinter den gleichen User 
verwendet und b) auf dem Server und dem Client dahinter das gleiche 
Passwort verwendet, also etwas was man nie machen sollte - erst recht 
nicht zum gleichen User-Namen, denn nur so merkt man den Unterschied 
nicht!

Trotzdem finden sich dutzende Anleitungen von Deppen die genau das 
machen und es auch noch verschweigen!

Richtig macht man es mit der Angabe des Users auf dem Client hinter dem 
SSH-Server:

ssh -l piUser -p 1999 localhost

Oder direkt vom Arbeitsplatzrechner aus:

ssh piUser@server.net -p 19999

Diese beiden letzten Varianten funktionierten immer problemlos, die 
erste nie.

: Bearbeitet durch User
von Daniel A. (daniel-a)


Lesenswert?

Rolf F. schrieb:
> Ich habe nun herausgefunden wieso es nicht funktionert und auch wieso 95
> % aller Anleitungen zu Reverse SSH Tunnel schlicht falsch sind weil sie
> nicht funktionieren

Diese 95% sind nicht falsch und sie funktionieren.

> Das
>
>   ssh localhost -p 1999
>
> auf dem Server macht, im Gegensatz zur Angabe der Passwortabfrage, den
> Login nicht auf dem localhost (Server) sondern auf dem Client hinter dem
> SSH-Server. Das localhost ist nämlich durch den Tunnel nicht der Server
> sondern der Client dahinter!

Hier liegt dein Denkfehler, oder eigentlich nicht Denkfehler, sondern 
Begriffsfehlinterpretierung. Das was hinter dem Tunnel ist ist kein 
Client, sondern ein Server. Der Client ist das Programm, welches die 
Verbindung initiiert, und der Server ist der, der auf eine Verbindung 
wartet.

Der Sinn hinter dem SSH Port Forwarding ist es, den Traffic der auf dem 
Port von einem Rechner eingeht durch einen Tunnel zu einem Port auf 
einem anderen Rechner weiterzuleiten, damit man von einem Rechner auf 
einen Dienst auf dem anderen Server zugreifen kann. Wenn man dies 
begriffen hat
weiss man, dass der Tunnel am Dienst keine Änderungen vornehmen kann, da 
der Tunnel nichts über den Dienst weiss, und wenn dieser Dienst 
Passwortgeschützt wurde dessen Passwort benötigt wird um darauf 
zuzugreifen.
Wenn du das nicht verstanden hattest, wusstest du effektiv nicht, was 
du, der SSH Tunnel und SSH Port Forwarding tun.

Rolf F. schrieb:
> Das Login kann daher mit dieser Kommandozeile nur funktionieren wenn man
> a) auf dem Server wie auf dem Client dahinter den gleichen User
> verwendet und b) auf dem Server und dem Client dahinter das gleiche
> Passwort verwendet, also etwas was man nie machen sollte - erst recht
> nicht zum gleichen User-Namen, denn nur so merkt man den Unterschied
> nicht!

Wenn jemand einen SSH Reverse Tunnel einrichten will, ist es ja wohl das 
mindeste voraussetzen zu können, dass derjenige schoneinmal eine SSH 
Verbindung aufgebaut hat und weiss, wie man eine normale SSH Verbindung 
als Benutzer XY aufbaut, oder dies zumindest in den Manpages nachschaut. 
Es ist nun wirklich nicht nötig auf eine derartige Trivialität bei jedem 
Beispiel und in jeder Anleitung erneut einzugehen.

Rolf F. schrieb:
> mit der Angabe des Users auf dem Client hinter dem SSH-Server
Korrekt wäre "mit der Angabe des Users auf dem Server hinter dem 
SSH-Tunnel"

von Erwin M. (nobodyy)


Lesenswert?

Daniel A. schrieb:
> Rolf F. schrieb:
>> Das
>>
>>   ssh localhost -p 1999
>>
>> auf dem Server macht, im Gegensatz zur Angabe der Passwortabfrage, den
>> Login nicht auf dem localhost (Server) sondern auf dem Client hinter dem
>> SSH-Server. Das localhost ist nämlich durch den Tunnel nicht der Server
>> sondern der Client dahinter!
>
> Hier liegt dein Denkfehler, oder eigentlich nicht Denkfehler, sondern
> Begriffsfehlinterpretierung. Das was hinter dem Tunnel ist ist kein
> Client, sondern ein Server. Der Client ist das Programm, welches die
> Verbindung initiiert, und der Server ist der, der auf eine Verbindung
> wartet.

Das "ssh localhost -p 1999" kann aber niemals funktionieren wenn man 
richtig konfiguriert hat, also niemals den gleichen Usernamen zweimal 
verwendet. Dann verwendet ssh nämlich automatisch den User-Namen auf dem 
lokalen Rechner, der nicht übereinstimmt mit dem User-Namen auf dem 
entfernten.

Schon beim ersten Google-Treffer zu "reverse ssh tunnel" zeigt sich das 
"ssh localhost -p <port>" ohne einen Hinweis dazu dass das nur unter 
speziellen Voraussetzungen funktionieren kann, die man niemals verwenden 
sollte:
https://www.howtoforge.com/reverse-ssh-tunneling

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.