it-swarm.com.de

SSH-L Verbindung erfolgreich, aber Localhost Port Forwarding funktioniert nicht

Mein Labor führt RStudio auf einem Server aus. Vor ein paar Wochen, aus dem Haus meines Cousins, ssh'd ich erfolgreich in den Server und zog das serverseitige RStudio über meinen lokalen Firefox-Browser hoch. Nun, wenn ich versuche, von zu Hause (über meinen eigenen Router) auf den Server RStudio zuzugreifen, funktioniert es nicht. Ich brauche Hilfe bei der Fehlerbehebung, und ich vermute, es liegt ein Problem am Router vor. Ich verwende Mac OSX 10.6.8. Keine Ahnung, was auf dem Universitätsserver läuft, aber ich glaube nicht, dass es sich um ein serverseitiges Problem handelt.

So funktionierte es beim ersten Mal im Haus meiner Cousine: erstens VPN in das Universitätsnetzwerk; dann rufe ich SSH mit Portweiterleitung an; dann öffne ich einen Firefox-Browser, stelle eine Verbindung zu meinem localhost-Port her und er öffnet RStudio auf der Serverseite, auf die ich über mein lokales Browserfenster zugreifen kann.

Hier ist das Problem, das ich gerade habe, wenn ich versuche, mich von meinem Heimnetzwerk aus anzumelden:

Ich kann die VPN-Verbindung erfolgreich herstellen. Ich kann SSH auch mit diesem Befehl erfolgreich einrichten: ssh -v -L 8783:localhost:8783 [email protected]

Hier sind die letzten Zeilen der ausführlichen Ausgabe des erfolgreichen Befehls ssh:

debug1: Authentication succeeded (password).
debug1: Local connections to LOCALHOST:8783 forwarded to remote address localhost:8783
debug1: Local forwarding listening on 127.0.0.1 port 8783.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 8783.
debug1: channel 1: new [port listener]
debug1: channel 2: new [client-session]
debug1: Entering interactive session.
Last login: Mon Sep  2 04:02:40 2013 from vpnipaddress

Ich glaube, ich bin immer noch erfolgreich auf der VPN- und SSH-Stufe (obwohl ich nicht weiß, warum mein letzter Login der 2. September war, als ich mich seitdem ein paar Mal angemeldet habe).

Als nächstes öffne ich Firefox und tippe localhost: 8783. Anstatt eine RStudio-Server-App durch mein Browserfenster zu bekommen, erhalte ich die folgenden Fehler:

Im Firefox-Browserfenster heißt es: Server nicht gefunden, Firefox kann den Server unter www.localhost.com nicht finden. Überprüfen Sie die Adresse auf Tippfehler usw.

Im Terminalfenster heißt es:

debug1: Connection to port 8783 forwarding to localhost port 8783 requested.
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: connect failed: Connection refused
debug1: channel 3: free: direct-tcpip: listening port 8783 for localhost port 8783, connect from 127.0.0.1 port 50420, nchannels 4

Ich bin nicht sicher, was ich falsch gemacht habe. Ich habe an meinem Laptop seit meiner letzten erfolgreichen Verbindung nichts geändert. Ich bin auf einem eigenen Router (anstelle meines Cousins), also muss ich mich vielleicht mit der Firewall beschäftigen? Ich habe bereits zugelassen, dass die Ports 22 und 8783 durch die Firewall zu meinem Laptop geleitet werden (ich bin mir nicht mal sicher, ob ich das tun müsste). Hilfe?

23
user2762495
ssh -v -L 8783:localhost:8783 [email protected]
...
channel 3: open failed: connect failed: Connection refused

Wenn Sie eine Verbindung zu Port 8783 auf Ihrem lokalen System herstellen, wird diese Verbindung über Ihren SSH-Link zum SSH-Server unter server.com getunnelt. Von dort stellt der SSH-Server TCP eine Verbindung zum Localhost-Port 8783 her und leitet Daten zwischen der getunnelten Verbindung und der Verbindung zum Ziel des Tunnels weiter.

Der Fehler "Verbindung abgelehnt" kommt vom ssh-Server auf server.com, wenn versucht wird, die TCP Verbindung zum Ziel des Tunnels herzustellen. "Verbindung abgelehnt" bedeutet, dass ein Verbindungsversuch abgelehnt wurde. Die einfachste Erklärung für die Ablehnung ist, dass auf server.com nichts auf Localhost-Port 8783 auf Verbindungen wartet. Mit anderen Worten, die Serversoftware, mit der Sie zu tunneln versuchten, wird nicht ausgeführt nicht an diesem Port zuhören.

53
Kenster

Posten, um jemandem zu helfen.

Symptom:

channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip:
   listening port 8890 for 169.254.76.1 port 8890,
   connect from ::1 port 52337 to ::1 port 8890, nchannels 8

Mein Szenario; Ich musste den Remote-Server als Bastion-Host verwenden, um eine Verbindung herzustellen. Endgültiges Ziel/Ziel: 169.254.76.1, Port 8890. Über einen Zwischenserver mit öffentlicher IP: ec2-54-162-180-7.compute-1.amazonaws.com

SSH-Portweiterleitungsbefehl:

ssh -i ~/keys/dev.tst -vnNT -L :8890:169.254.76.1:8890
[email protected]

Das Problem war: Es war kein Dienst an Port 8890 im Zielhost gebunden. Ich hatte vergessen, den Dienst zu starten.

Wie habe ich Probleme beim Schießen?

SSH in Bastion Host und dann locken.

Hoffe das hilft.

1
AravindR

Ich hatte dieses Problem, als ich eine VNC-Verbindung über einen Tunnel herstellen wollte. Aber der vncserver lief nicht. Ich habe es gelöst, indem ich den Kanal auf dem Remote-Computer mit vncserver :3.

0
friedrich

Vielleicht ist es zu spät, aber ich bin auf dasselbe Problem gestoßen und wollte nicht Port für Port abbilden, also habe ich mein /etc/ssh/sshd_config Datei und hinzugefügt:

AllowTCPForwarding yes PermitOpen any

Dann starte einfach ssh neu

0
Walucas

Hinweis: localhost ist der Hostname für eine Adresse, die die lokale Netzwerkschnittstelle (Loopback) verwendet, und 127.0.0.1 Ist ihre IP im IPv4-Netzwerk Standard (es ist ::1 in IPv6). 0.0.0.0 Ist die "aktuelle Netzwerk" -IP-Adresse des IPv4-Standards.

Ich habe diesen Fehler bei einem Docker-Setup festgestellt. Ich hatte einen Docker-Container auf einem externen Server und hatte seine Ports (korrekt) als 127.0.0.1:9232:9232 Zugeordnet. Durch Portweiterleitung ssh remote -L 9232:127.0.0.1:9232 Hätte ich erwartet, dass ich mit dem Port remote des Servers 9232 Kommunizieren kann, als wäre es mein eigener lokaler Port.

Es stellte sich heraus, dass der Docker-Container seinen Prozess intern mit 127.0.0.1:9232 Und nicht mit 0.0.0.0:9232 Ausführte. Obwohl ich die Portzuordnungen des Containers korrekt angegeben hatte, waren sie nicht korrekt Schnittstelle zum Ausplanen.

0
Jamie Birch

Ich habe dieses ähnliche Problem gelöst, weil "localhost" auf dem Server nicht verfügbar war, als der Netzwerkdienst neu gestartet wurde, z. 'ifdown -a', aber nur 'ifup -eo1'. Abgesehen davon, dass der Server den Port nicht überwacht, können Sie auch prüfen, ob "localhost" verfügbar ist oder nicht. 

ps: Post es einfach, dass jemand mit dem ähnlichen Problem davon profitieren kann.

0
Xiaoyan Zhuo