ssh auf private-ip


18

Ich habe einen Computer mit CentOS (Computer A), der eine private IP 10.150.5.141 (mit eingeschränkter Firewall) hat, kann auf das Internet und mein ArchLinux VPS (Computer B) mit echter IP wxyz zugreifen

Wie kann ich einen anderen PC (Computer C) einrichten, der auf Computer B zugreifen kann, um eine Verbindung zu Computer A herzustellen, aber Computer C kann keine direkte Verbindung zu Computer A herstellen (weil er sich im eigenen privaten Netzwerk von A befindet)?

Ich weiß, dass ein Tunnel lokale Ports für einen anderen Computer öffnen kann: Port, aber wie soll man das Gegenteil tun?

Ich möchte sshüber Computer B auf Computer A zugreifen, aber Computer B kann nicht auf Computer A zugreifen, da das Netzwerk auf Computer A eingeschränkt ist (kann ausgehen, kann aber nicht eingehen, da ich keinen Zugriff auf den Router habe).

Ich möchte so etwas:

ssh -connect-to w.x.y.z:22 -open-port vvv -forward-to 10.150.5.141 -port 22

so dass, wenn ich ssh w.x.y.z:vvvvon Computer C wird es zu privaten Netzwerk weitergeleitet 10.150.5.141:22.

Antworten:


14

Was Sie suchen, ist ein umgekehrter Tunnel. sshbietet es durch den -RSchalter:

-R [bind_address:]port:host:hostport
       Specifies that the given port on the remote (server) host is to 
       be forwarded to the given host and port on the local side.  This 
       works by allocating a socket to listen to port on the remote side, 
       and whenever a connection is made to this port, the connection is
       forwarded over the secure channel, and a connection is made to host 
       port hostport from the local machine.

Wie das OP mit seiner Antwort feststellte, lautet die Syntax wie folgt:

$ ssh -f -N -R vvv:localhost:22 w.x.y.z

Beispiel

Ich habe 2 Computer im Netzwerk lappyund remotey. Also führe ich den folgenden Befehl aus lappy:

$ ssh -f -N -R 12345:localhost:22 remotey

Ich kann bestätigen, dass es funktioniert:

$ ps -eaf|grep "[l]ocalhost:22"
saml     27685     1  0 11:10 ?        00:00:00 ssh -f -N -R 12345:localhost:22 remotey

Wenn ich jetzt sshseparat zum fernen System übergehe remoteyund diesen Befehl ausführe, kann ich sehen, dass es jetzt Verbindungen an Port 12345 auf der lokalen Schnittstelle des fernen Systems akzeptiert:

$ netstat -an|grep :12345
tcp        0      0 127.0.0.1:12345             0.0.0.0:*                   LISTEN      
tcp        0      0 ::1:12345                   :::*                        LISTEN      

Verbindung testen

Sie können sehen, dass der umgekehrte SSH-Tunnel wie folgt funktioniert.

  1. Einloggen in remotey

    [user@lappy ~]$ ssh remotey
    
  2. Testen Sie den Reverse-Tunnel-Port

    [user@remotey ~]$ ssh -p 12345 localhost
    
  3. sollte jetzt wieder auf lappy sein

    user@localhost's password: 
    Last login: Thu Aug  1 17:53:54 2013
    /usr/bin/xauth:  creating new authority file /home/user/.Xauthority
    [user@lappy ~]$ 
    

Ports an anderen Schnittstellen als localhost ( lo)?

Möglicherweise kratzen Sie sich am Kopf, wenn Sie einen Befehl wie diesen ausführen, der anscheinend nicht funktioniert, oder er wird immer an einen Port auf der localhost ( lo) - Schnittstelle gebunden .

Beispielsweise:

lappy$ ssh -f -N -R remotey:12345:lappy:22 remotey

HINWEIS: Dieser Befehl fordert Sie auf, Port 12345 @ remotey zu öffnen und alle Verbindungen zu Port 22 @ lappy zu tunneln.

Dann auf fernbedienung:

remotey$ netstat -an|grep 12345
tcp        0      0 127.0.0.1:12345              0.0.0.0:*                   LISTEN   

In den sshdKonfigurationen ist dies nicht möglich. Tatsächlich können Sie ohne diese aktivierte Funktion ( GatewayPorts) keine sshTunnel-Ports an etwas anderes als localhost binden .

Aktivieren von GatewayPorts

remotey$ grep GatewayPorts /etc/ssh/sshd_config
#GatewayPorts no

Bearbeiten Sie diese Datei, um sie zu aktivieren /etc/ssh/sshd_config:

GatewayPorts clientspecified

Und neu starten sshd:

remotey$ sudo service sshd restart

Versuchen Sie es jetzt noch einmal und wir sollten den Effekt sehen, nach dem wir suchen:

lappy$ ssh -f -N -R remotey:12345:lappy:22 remotey

Und überprüfen Sie es noch einmal auf der Fernbedienung:

remotey$ netstat -anp | grep 12345
tcp        0      0 192.168.1.3:12345           0.0.0.0:*                   LISTEN      9333/sshd

HINWEIS: Oben sehen wir, dass der sshdProzess jetzt die Schnittstelle mit der IP-Adresse 192.168.1.3 auf Verbindungen an Port 12345 überwacht.

Verbindung testen (part deux)

Jetzt mit unserem veränderten Setup, als wir es diesmal testen. Der Hauptunterschied ist, dass wir uns nicht mehr mit localhost verbinden müssen!

  1. Einloggen in remotey

    [user@lappy ~]$ ssh remotey
    
  2. Testen Sie die umgekehrte Verbindung

    [user@remotey ~]$ ssh -p 12345 remotey
    
  3. sollte jetzt wieder auf lappy sein

    root@remotey's password: 
    Last login: Wed Aug 21 01:49:10 2013 from remotey
    [user@lappy ~]$ 
    

Verweise


Gibt es eine Möglichkeit, Tunnel von 0.0.0.0:12346 auf 127.0.0.1:12345 auf demselben Computer zu erstellen?
Kokizzu

1
@Kokizzu - Ich habe versucht, dies einzurichten, und werde auf das, wonach du fragst, um die Achse gewickelt. Ich fand das, was sich anhört wie das, was Sie wollen, anattatechnologies.com/q/2012/08/chaining-ssh-tunnels . Ich werde versuchen, es später heute Abend auszuarbeiten, und Sie können gerne damit spielen. Lassen Sie mich wissen, ob Sie damit Fortschritte erzielen.
SLM

Das ist nicht das, was ich gemeint habe, ich möchte, dass es an wxyz gebunden wird: vvv2 anstelle von 127.0.0.1 (auf Computer B), damit andere Leute es auch verwenden können.
Kokizzu

1
@ Kokizzu - siehe Updates.
SLM

2

Da Computer B nicht auf Computer A zugreifen kann, müssen Sie zuerst einen Remote-Tunnel von Computer A aus öffnen.

ssh user@computerB -R vvv:localhost:22

Danke, aber gibt es eine Möglichkeit, einen Port auf der IP von eth0 zu öffnen, der an einen Dienst weitergeleitet wurde, der localhost abgehört hat?
Kokizzu

1

egal, ich habe die Antwort gefunden:

ssh -f -N -R vvv:localhost:22 w.x.y.z

vom Computer A

EDIT: TL; DR, richtige Lösung:

ssh -f -N -R w.x.y.z:vvv:localhost:22 w.x.y.z
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.