ssh-Tunnel, reverse und anders herum

[smutbert]

Hallo liebe Leute,

die ssh-Manpage treibt mich zur Verzweiflung, weil mir nicht klar ist, ob ich es richtig herum probiere.
Es geht um den Tunnel aus diesem Thread viewtopic.php?f=30&t=180911&p=1271415#p1271500 der in der Form seinen Zweck erfüllt

Code: Alles auswählen

computer1 $ ssh -R 9999:127.0.0.1:4713 benutzer@computer2

Ich hätte gerne einen Tunnel mit derselben Funktion vom anderen Computer aus aufgebaut, aber so funktioniert es schon einmal nicht

Code: Alles auswählen

computer2 $ ssh -L 9999:localhost:4713 benutzer@computer1

(ich bin mir nicht sicher ob es jetzt am Tunnel oder etwas anderem liegt und wüsste gerne wo ich den Fehler suchen soll)

[habakug]

Hallo,

schonmal so probiert?

Code: Alles auswählen

computer2 $ ssh -L 9999:<IP-computer1>:4713 benutzer@computer1

Gruss, habakug

[MSfree]

Kennst du

Code: Alles auswählen

man ssh_config

Ich bevorzuge es, meine Konfiguration in einer Datei abzulegen, der Syntax der Datei und alle Optionen sind in der Manpage beschrieben. Interessant sind hier vor allem:

Code: Alles auswählen

LocalForward LocalPortNumber RemoteHost:RemotePort

Beispiel:

Code: Alles auswählen

LocalForward 10025 MyMailServer.domain.tld:25

Legt ein Forward des lokalen Ports 10025 auf den entfernten Mailserverport 25. Wenn du im Thunderbird als Outgoing Server localhost:10025 konfigurierst, könntest du über den SSH-Tunnel Emails verschicken. Dabei muß die SSH-Verbindung nicht einmal zum Hoist "MyMailServer.domain.tld" aufgebaut werden. Man könnte mit der Konfiguration auch eine SSH-Verbindung zu MySSHServer.otherdomain.tld aufbauen, dann wird der Forward zwischen MySSHServer.otherdomain.tld und MyMailServer.domain.tld etabliert, sobald man sich per SSH mit MySSHServer.otherdomain.tld verbunden hat.

und

Code: Alles auswählen

RemoteForward RemotePort HostNameInLocalNet:LocalPort

Man kann solche Konfigurationsdateien auch nutzen, um mehrere Ports über eine SSH-Verbindung zu tunneln. Du könntest das evebtuell sogar nutzen, um über eine Verbindung den lokalen Port und den remote Port zu tunneln. Insgesamt finde ich den Syntax übersichtlicher und leichter lesbar als die Kommandozeilenoptionen.

[smutbert]

Danke Habakug, es funktioniert!

Code: Alles auswählen

ssh -L 9999:127.0.0.1:4713 benutzer@computer1
ssh -L 9999:<IP-computer1>:4713 benutzer@computer1

Bei der Variante mit 127.0.0.1 führt der Tunnel zum Loopbackinterface von Computer 1 führt und unter Angabe der „echten“ IP-Adresse zur physischen Netzwerkschnittstelle.

Was nicht funktioniert ist

Code: Alles auswählen

ssh -L 9999:localhost:4713 benutzer@computer1

(ist mir nicht klar, wieso das nicht funktioniert)

Kennst du

Code: Alles auswählen

man ssh_config

Eigentlich schon, aber gedacht habe ich daran natürlich nicht und die ssh-Manpage ist zu lang um zufällig über „SEE ALSO“ zu stolpern
Leichter lesbar ist es so auf jeden Fall, Danke.

[Tintom]

Löst localhost zu 127.0.0.1 auf?
Mich wundert es, weil ich die Weiterleitungen ausschließlich in der Variante mache, die bei dir nicht funktioniert.

[smutbert]

Auf die Idee das zu prüfen bin ich nicht gekommen. In der »/etc/hosts« habe ich auf keinem der beteiligten Systeme einen Eintrag für localhost oder 127.0.0.1.
Die Auflösung übernimmt soweit ich das durchblicke systemd-resolved und am Ende libnss-myhostname:

Code: Alles auswählen

$ nslookup localhost
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	localhost
Address: 127.0.0.1
Name:	localhost
Address: ::1

ping localhost wählt ::1 als Ziel – könnte das die Ursache sein, wenn ich im physischen Netzwerk sonst nur ip4 konfiguriere und verwende?

[habakug]

Hallo,

Code: Alles auswählen

# ping -4 localhost

sollte 127.0.0.1 wählen.
Ich kann aber ein seltsames Verhalten nachvollziehen. Der Tunnel

Code: Alles auswählen

# ssh -vvv -L 9999:127.0.0.1:4713 192.168.0.48

funzt in einer Richtung nicht ("Connection refused"):

Code: Alles auswählen

debug1: Connection to port 9999 forwarding to 127.0.0.1 port 4713 requested.
debug2: fd 8 setting TCP_NODELAY
debug2: fd 8 setting O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug1: channel 2: new [direct-tcpip]
debug3: send packet: type 90
debug3: receive packet: type 92
channel 2: open failed: connect failed: Connection refused
debug2: channel 2: zombie
debug2: channel 2: garbage collecting
debug1: channel 2: free: direct-tcpip: listening port 9999 for 127.0.0.1 port 4713, connect from ::1 port 47252 to ::1 port 9999, nchannels 3

in der anderen Richtung schon:

Code: Alles auswählen

debug1: Connection to port 9999 forwarding to 127.0.0.1 port 4713 requested.
debug2: fd 8 setting TCP_NODELAY
debug2: fd 8 setting O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug1: channel 2: new [direct-tcpip]
debug3: send packet: type 90
debug3: receive packet: type 91
debug2: channel 2: open confirm rwindow 2097152 rmax 32768

Es wird an IPv4 gelauscht und die Verbindung über IPv6 angenommen...

Kaum entfernt man die Kommentarzeichen aus der sshd_config

Code: Alles auswählen

[...]
Port 22
AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::
[...]

funzt es in beide Richtungen.

Gruss, habakug

[smutbert]

Ist so ein ssh-Tunnel denn in beide Richtungen offen?

Ich habe das so verstanden, dass z. B. bei -L 9999:127.0.0.1:4713 ssh lokal an Port 9999 lauscht und an dem Port 4713 des ssh-Servers weiterleitet, aber nicht auch umgekehrt?

[Tintom]

Ist so ein ssh-Tunnel denn in beide Richtungen offen?

Ich habe das so verstanden, dass z. B. bei -L 9999:127.0.0.1:4713 ssh lokal an Port 9999 lauscht und an dem Port 4713 des ssh-Servers weiterleitet, aber nicht auch umgekehrt?

Ja, unabhängig ob der Tunnel mit -L oder -R gestartet wird, können Daten in beide Richtungen übertragen werden.

Vielleicht wird es so übersichtlicher:
Lokal Remote
-L 9999:127.0.0.1:4713 -> Verbinde den lokalen Port 999 mit Port 4713 der Netzwerkschnittstelle 127.0.0.1 auf der entfernten Maschine
-R 9999:127.0.0.1:4713 -> Baue einen Tunnel zwischen Port 9999 der Remotemaschine und Port 4713 der lokalen Netzwerkschnittstelle 127.0.0.1

Kaum entfernt man die Kommentarzeichen aus der sshd_config

Code: Alles auswählen

[...]
Port 22
AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::
[...]

funzt es in beide Richtungen.

Das wäre laut man sshd_config das Standardverhalten: Akzeptiere IPv6 und IPv4 und lausche auf jedem Interface. Schon merkwürdig warum das vorher nicht funktioniert hat

[smutbert]

Mit dem Wissen, dass der Tunnel keine Einbahn ist und der ip4/ip6-Geschichte ist mir dann das meiste klar, denke ich.
Danke noch einmal.