[Gelöst] Zwei PCs mit DSL-Lite. ssh-tunnel IPv4 über einen Server im Web

[egerlach]

Hallo,
2x DSL Lite (also kein IPv4 mehr), es soll aber eine SSH-Verbindung zwischen beiden hergestellt werden. Wie geht das?

Das habe ich versucht: vom entfernten "remotePC" einen revers-tunnel auf den Web-Server:

Code: Alles auswählen

remotePC# ssh -R *:2099:localhost:22 root@meinWebserver.de  

Dann komme ich auf dem Webserver per ssh -p 2099 auf den remotePC. Der Revers-tunnel funktioniert also.
Wie schalte ich jetzt ein Tunnel von meinPC auf den Webserver Port 2099? - Ein

Code: Alles auswählen

meinPC# ssh -L 2222:localhost:2099 root@meinWebserver.de     
 oder statt localhost die feste IPv4 des Webserver, der hat ene IPv4, zum Beispiel 84.34.21.76 

funktioniert nicht, ich kann mich zwar einloggen, aber wenn ich dann an meinPC ein ssh -p 2222 mache kommt nur:

Code: Alles auswählen

meinPC# ssh -p 2222 localhost
kex_exchange_identification: read: Connection reset by peer

genauer:

Code: Alles auswählen

meinPC# ssh -v -p 2222 localhost
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: Connection established.
debug1: identity file /home/gerlach/.ssh/id_rsa type 0
debug1: identity file /home/gerlach/.ssh/id_rsa-cert type -1
debug1: identity file /home/gerlach/.ssh/id_dsa type 1
debug1: identity file /home/gerlach/.ssh/id_dsa-cert type -1
debug1: identity file /home/gerlach/.ssh/id_ecdsa type 2
debug1: identity file /home/gerlach/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/gerlach/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/gerlach/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/gerlach/.ssh/id_ed25519 type -1
debug1: identity file /home/gerlach/.ssh/id_ed25519-cert type -1
debug1: identity file /home/gerlach/.ssh/id_ed25519_sk type -1
debug1: identity file /home/gerlach/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/gerlach/.ssh/id_xmss type -1
debug1: identity file /home/gerlach/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
kex_exchange_identification: read: Connection reset by peer

meinWebserver.de hat Debian Buster installiert, meinPC hat ubuntu.


Das meldet bei dem ssh -p 222 localhost meinWebsever.de im syslog:

Code: Alles auswählen

channel 3: open failed: connect failed: Connection refused

Der ssh-call durch port 2222 kommt bei meinWebserver.de durch den -L -Tunnel an. Wird dann von meinWebserver "reset'et". Also ist der Fehler auf meinWebserver.de zu suchen.

Ich vermute irgendwelche sshd-Einstellungen in sshd_config. Ein echo "1" > /proc/sys/net/ipv4/ip_forward bringt nichts.
Wer weiss weiter?
Danke schon mal
Eckard

[bluestar]

Hallo,
2x DSL Lite (also kein IPv4 mehr), es soll aber eine SSH-Verbindung zwischen beiden hergestellt werden. Wie geht das?

Am einfachsten geht dies, wenn du deine SSH-Verbindung über IPv6 laufen lässt. Den jeweiligen Interface-Identifier im Router für eingehende Verbindungen auf Port 22 TCP freischalten und dann direkt via SSH von Host A auf Host B zugreifen, der Server im Netz ist da gar nicht mehr von Nöten.

[egerlach]

Es wird sicherlich keine Freischaltung eines "Interface-Identifier" geben, vielleicht in ein paar Jahren. So eine "Sicherheitslücke" wird gewiss nicht seitens des remote-LAN genehmigt. Der "Router", den Du nennst, ist übrigens nicht der einzige, es wir auch noch mit einem zweiten Router (zweiter FritzBox) ge'NAT'et. Da kommt ich dann letztlich nicht durch.
A propos: welches DSL Lite lässt eine Freischaltung eines "Interface-Identifier zu? Wird mit DSL-Lite nicht gerade aus Kompatibilitätsgründen mit IPv4-only-Servern weltweit alles noch mit IPv4 geroutet? Müßte dieser Anschluss mit einem geöffneten Interface-Identifier dann reines IPv6 machen, wäre also von IPV4-Server abgehängt?

Es wird ja wohl nicht so schwer sein über einen dritten Server im Web per IPv4 zu tunneln ... anydesk, teamviewer, ... machen das täglich millionenfach. Wer weiss wie das geht?

[uname]

Ich würde den Provider wechseln.

Ein paar Ideen:

Code: Alles auswählen

remotePC# ssh -R *:2099:localhost:22 root@meinWebserver.de  

Kenne ich nur ohne *:

Code: Alles auswählen

remotePC# ssh -R 2099:localhost:22 root@meinWebserver.de  

authorized_hosts nicht testen beim zweiten SSH-Befehl:

Code: Alles auswählen

ssh -o StrictHostKeyChecking=no

SSH-Port-Forwarding überprüfen (den Befehl kannte ich nicht, mag auch nicht zutreffen, schau "man sshd_config")

Code: Alles auswählen

GatewayPorts yes

Logs posten

Code: Alles auswählen

cat /var/log/auth.log

Kommt irgendwas am SSH-Server an?
Kannst dich ja mal mit strace dranhängen

[bluestar]

Es wird sicherlich keine Freischaltung eines "Interface-Identifier" geben, vielleicht in ein paar Jahren. So eine "Sicherheitslücke" wird gewiss nicht seitens des remote-LAN genehmigt.

Ah du hast also auf beiden Seiten keine Chance das Setup ordentlich zu machen, da nicht beide Seiten unter deiner Kontrolle stehen.

Der "Router", den Du nennst, ist übrigens nicht der einzige, es wir auch noch mit einem zweiten Router (zweiter FritzBox) ge'NAT'et. Da kommt ich dann letztlich nicht durch.

Na das macht das Leben nicht unbedingt einfacher.

A propos: welches DSL Lite lässt eine Freischaltung eines "Interface-Identifier zu? Wird mit DSL-Lite nicht gerade aus Kompatibilitätsgründen mit IPv4-only-Servern weltweit alles noch mit IPv4 geroutet? Müßte dieser Anschluss mit einem geöffneten Interface-Identifier dann reines IPv6 machen, wäre also von IPV4-Server abgehängt?

Bei DS-Lite bekommst du im Normalfall einen vollwertigen IPv6 Zugang und einen "kastrierten" IPv4 Zugang.

Es wird ja wohl nicht so schwer sein über einen dritten Server im Web per IPv4 zu tunneln ... anydesk, teamviewer, ... machen das täglich millionenfach. Wer weiss wie das geht?

Es ist nicht schwer, aber dennoch deutlich aufwendiger als direkt auf beiden Seiten nativ IPv6 zu sprechen und den ganzen NAT-, Tunnel-Krams, Zwischen-Server hinter sich zu lassen.

[mat6937]

... anydesk, teamviewer, ... machen das täglich millionenfach. Wer weiss wie das geht?

Das geht z. B. mit "udp hole punching" und/oder mit "tcp hole punching".

[TomL]

Es wird sicherlich keine Freischaltung eines "Interface-Identifier" geben, vielleicht in ein paar Jahren. So eine "Sicherheitslücke" wird gewiss nicht seitens des remote-LAN genehmigt. Der "Router", den Du nennst, ist übrigens nicht der einzige, es wir auch noch mit einem zweiten Router (zweiter FritzBox) ge'NAT'et.

- Was ist ein Interface-Identifier?
- Warum ist das eine Sicherheitslücke?
- Global-Unicast-IPv6 werden genattet?

Es wird ja wohl nicht so schwer sein über einen dritten Server im Web per IPv4 zu tunneln ... anydesk, teamviewer, ... machen das täglich millionenfach.

Ja, indem sie unkontrollierbare Sicherheitslücken öffnen...

[bluestar]

- Was ist ein Interface-Identifier?

Einfach gesagt, die letzten 64 Bit einer IPv6-Adresse, näheres dazu bei Wikipedia, siehe hier: https://de.wikipedia.org/wiki/IPv6#Auft ... dressraums

[egerlach]

[...]
SSH-Port-Forwarding überprüfen (den Befehl kannte ich nicht, mag auch nicht zutreffen, schau "man sshd_config")

Code: Alles auswählen

GatewayPorts yes

[...]

Das war's!!! 1000 Dank!


*** GELÖST ***

[habakug]

Hallo,

zu beachten ist jedoch, das mit

Code: Alles auswählen

GatewayPorts yes

jeder aus dem Internet auf den/die Ports zugreifen darf.
Es gibt aber auch

Code: Alles auswählen

GatewayPorts clientspecified

Jetzt kann mit -R [bind_address:]port:host:hostport eine Bind-Adresse angegeben werden.

Gruss, habakug

[egerlach]

Danke für den Hinweis! Das ist natürlich wesentlich sicherer!
Was ist denn dieses "bind" dann? Eine IP-Adresse? - Habe meine IPv4 (DSL-Lite) genommen, das funktioniert aber nicht (liegt es am DSL-lite, weil eigentlich die IPv6 gemeldet wird?). Finde nirgends ein Beispiel. Kannst Du mir ein Beispiel nennen für einen ssh -R [bindaddr]:port:localhost:22 ?

[Tintom]

Wenn ich das richtig interpretiere:

-R [bind_address:]port
[...]
By default, TCP listening sockets on the server will be bound to the loopback interface only. This may be overridden by
specifying a bind_address. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on
all interfaces. Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see
sshd_config(5)).

dann solltest du mit ssh -R 2099:localhost:22 root@meinWebserver.de (Also explizit kein Asterisk für die bind_adress) die Änderung an der sshd_config sparen können, weil das loopback interface für ssh ausreicht. Weiterhin kannst du ssh noch die Option -N mitgeben, wenn nur der Tunnel aufgebaut werden soll. Das verhindert, dass der Tunnel durch das versehentliche Beenden von ssh zusammenbricht.

[egerlach]

Jetzt verstehe ich nichts mehr: öffne ich einen ZWEITEN (!!) revers-Tunnel vom remotePC

Code: Alles auswählen

ssh -R 2099:localhost:22 meinWebserver.de

dann komme ich darüber rein auch bei "Gateway no" oder auskommentiert, nachdem ich vorher von meinem PC: ssh -L 2222:localhost:2099 meinWebserver.de gemacht habe, also dann per ssh -p 2222 root@localhost!! Der Hammer! Versteht das einer? Ich meine ich hätte das alles früher schon x-Male probiert, damals ging es nicht. Es kann auch *: vor der 2099 stehen, auch dann gehts. (Ich lasse es aber mal sicherheitshalber weg, das *: ist eine ein "größere Einladung"). Also:

Code: Alles auswählen

ssh -R *:2099:localhost:22 meinWebserver.de

Mit dem ersten tunnel vom remotePC mit gleicher Syntax gehts NICHT! Ob mit *: oder ohne vor dem Port 2098. Da ist immer die Fehlermeldung "channel 3: open failed: connect failed: Connection refused" die ich im OP dieser Diskussion genannt habe. Der erste Tunnel ist übrigens mit *: vor dem Port, dann zumindest funktioniert das Weiterleiten über den zweiten Tunnel.

Das Wichtige bei Konfiguration jetzt ist: dass dieser Port 2099 (und 2098) NICHT von jedem im Web erreichbar ist, sollte auch nicht, es ist ja auch "Gateway ... " auskommentiert. Habe sshd stets neu restarted, habe meinWebserver sogar gerade mal neu gebootet, weil ich es nicht glaubte, dass es jetzt ohne Gateway yes oder clientspecific geht.

Ist das ein ssh bug?

Code: Alles auswählen

# sshd -v
unknown option -- v
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d  10 Sep 2019

Jetzt habe ich was ich brauche, eine Möglichkeit paarmal pro Jahr einen ssh-tunnel direkt zu einem remotePC zu schalten aber auf meinWebserver als Zwischenserver ist alles dicht, von irgendwo im Web ist kein Port offen. Natürlich kommt das mit ssh -g -L ... , Gateway clientspecified, .. in meine ssh-Sammlung, samt Link auf diese Diskussion wenn das irgendwann mal nicht mehr geht.