youatwork@officepc$ autossh -R 12345:localhost:22 notroot@serverpc
Später:
you@homepc$ autossh -L 23456:localhost:12345 notroot@serverpc
you@homepc$ ssh youatwork@localhost -p 23456
Was Sie tun könnten, ist Folgendes: In Schritt 1 leiten Sie einen Remote-Port vom Büro-PC an den Server weiter ( 12345wird als Beispiel verwendet, sollte jeder Port> 1024 tun). Wenn Sie jetzt eine Verbindung zu 12345 auf dem Server herstellen, sollten Sie eine Verbindung zu Port 22 auf dem OfficePC herstellen.
In Schritt 2 leiten Sie den Port 23456 von Ihrem Heimcomputer an 12345 auf dem Server weiter (von wo aus er an officepc: 22 weitergeleitet wird, wie in Schritt 1 eingerichtet).
In Schritt 3 stellen Sie mit Ihrem Office-PC-Login eine Verbindung zum lokalen Port 23456 her . Dies wird in Schritt 2 an den Port 12345 auf Ihrem Server und in Schritt 1 an Ihren Büro-PC weitergeleitet.
Beachten Sie, dass ich autossh für die Weiterleitungen verwende, da es sich um einen SSH-Wrapper handelt, der den Tunnel automatisch wieder verbindet, wenn er getrennt wird. aber normales ssh würde genauso gut funktionieren, solange die verbindung nicht unterbrochen wird.
Es gibt eine mögliche Sicherheitsanfälligkeit: Jeder, der eine Verbindung zu localhost: 12345 auf dem Server-PC herstellen kann, kann jetzt eine Verbindung zu officepc: 22 herstellen und versuchen, sich darin zu hacken. (Beachten Sie, dass Sie einen SSH-Server auf jeden Fall oberhalb der standardmäßig aktivierten grundlegenden Schutzfunktionen sichern sollten. Ich empfehle, mindestens die Root-Anmeldung und die Kennwortauthentifizierung zu deaktivieren - siehe z. B. diese )
Bearbeiten : Ich habe dies mit der gleichen Konfiguration überprüft, und es funktioniert. GatewayPorts noBetroffen sind nur die Häfen, die weltweit geöffnet sind, nicht die lokalen Tunnel. Dies sind die weitergeleiteten Ports:
homepc:
outgoing ssh to serverpc:22
listening localhost:23456 forwarded through ssh tunnel
serverpc:
listening ssh at *:22
incoming localhost ssh tunnel (from homepc) forwarded to localhost:12345
listening localhost ssh tunnel (from officepc) forwarded from localhost:12345
officepc:
outgoing ssh to serverpc:22
incoming localhost through ssh tunnel (from serverpc) forwarded to localhost:22
In Bezug auf den Netzwerkstack handelt es sich also ausschließlich um lokalen Datenverkehr auf den jeweiligen Loopback-Schnittstellen (plus SSH- Verbindungen zum Server-PC). wird daher überhaupt GatewayPortsnicht geprüft.
Es gibt jedoch die Anweisung AllowTcpForwarding: Wenn nodies der Fall ist , schlägt dieses Setup fehl, da überhaupt keine Weiterleitung zulässig ist, auch nicht über die Loopback-Schnittstelle.
Vorsichtsmaßnahmen :
bei Verwendung von autossh und den letzten ssh, können Sie ssh verwenden ServerAliveIntervalund ServerAliveCountMaxfür den Tunnel nach oben zu halten. Autossh hat eine eingebaute Prüfung, aber anscheinend hat es einige Probleme mit Fedora. -M0Deaktiviert dies und -oServerAliveInterval=20 -oServerAliveCountMax=3prüft, ob die Verbindung hergestellt wurde. Versuche alle 20 Sek., wenn der Verbindungsaufbau dreimal hintereinander fehlschlägt, stoppt ssh (und autossh erstellt eine neue):
autossh -M0 -R 12345:localhost:22 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
Es kann nützlich sein, den SSH-Tunnel neu zu starten, wenn die Weiterleitung fehlschlägt. Verwenden Sie dazu -oExitOnForwardFailure=yes- Wenn der Port bereits gebunden ist, erhalten Sie möglicherweise eine funktionierende SSH-Verbindung, aber keinen weitergeleiteten Tunnel.
Verwenden ~/.ssh/configfür die Optionen (und Ports) ist ratsam, sonst werden die Befehlszeilen zu ausführlich. Zum Beispiel:
Host fwdserverpc
Hostname serverpc
User notroot
ServerAliveInterval 20
ServerAliveCountMax 3
ExitOnForwardFailure yes
LocalForward 23456 localhost:12345
Dann können Sie nur den Server-Alias verwenden:
autossh -M0 fwdserverpc