"Kanal 3: Öffnen fehlgeschlagen: administrativ verboten: Öffnen fehlgeschlagen" beim Erstellen einer VNC-Sitzung in einem SSH-Tunnel

Beim Erstellen einer VNC-Verbindung über eine getunnelte SSH-Verbindung wird folgende Fehlermeldung angezeigt:

channel 3: open failed: administratively prohibited: open failed

Ich habe festgestellt, dass dies nur passiert, wenn ich nicht lokal beim Host als usernameauf dem Host angemeldet bin, zu dem ich über eine getunnelte VNC-Verbindung eine Verbindung herstellen möchte. SSH-Tunnel:

ssh -p 6000 -L 5901:127.0.0.1:5901 username@192.168.0.2

VNC-Verbindung:

vncviewer localhost:1

Ich habe versucht, die Einstellungen /etc/ssh/sshd_configmit AllowTunnel yesund ohne Einstellung anzupassen . (Ich habe ssh nach jeder Änderung neu gestartet :) service ssh restartDer Fehler verschwindet jedoch, wenn auf dem Remote-Host eine lokale Sitzung ausgeführt wird (dh ich bin als usernamelokal angemeldet ). Wird dieses Verhalten von anderen Personen angezeigt? Es scheint, als ob ich in der Lage sein sollte, einen VNC remote zu starten und darauf zuzugreifen, ohne mich auch lokal anmelden zu müssen.

— Mike Swartz
quelle

Mike, bitte überprüfen Sie die Tour, um zu sehen, wie diese Website funktioniert. Wenn meine Antwort Ihr Problem gelöst hat, akzeptieren Sie sie bitte.

— Jakuje

Antworten:

Die Option, nach der Sie suchen, ist nicht AllowTunnel(dies gilt für die VPN- und Level 3-Weiterleitung mit tunGeräten). Sie suchen nach einer Lösung für AllowTcpForwardingdie lokale und Remote-Port-Weiterleitung von TCP-Verkehr in ssh.

Sehen Sie sich an, welche Werte sich auf Ihrem Server befinden, und ändern Sie sie in yes:

AllowTcpForwarding yes

— Jakuje
quelle

Vielen Dank für Ihre schnelle Antwort. Das scheint mein Problem behoben zu haben. Ich hatte andere mit dem gleichen Problem gesehen und ein Vorschlag war AllowTunnel yesin sshd_config, aber das funktionierte nicht für mich.

— Mike Swartz

Es ist wahrscheinlich eine urbane Legende, da auch die andere Antwort hierher kam. Keine Ahnung, woher es kam und es ist so einfach, die Handbuchseite zu öffnen und die Bedeutung zu überprüfen. Wenn es für Sie funktioniert, nehmen Sie sich eine Sekunde Zeit, um die Antwort als Lösung zu überprüfen und anderen zu helfen.

— Jakuje

Warum die Abstimmung?

— Jakuje

AllowTcpForwarding Gibt an, ob die TCP-Weiterleitung zulässig ist. Die verfügbaren Optionen sind "Ja" oder "Alle", um die TCP-Weiterleitung zuzulassen, "Nein", um die gesamte TCP-Weiterleitung zu verhindern, "Lokal", um nur die lokale (aus Sicht von SSH (1)) Weiterleitung zuzulassen, oder "Remote", um die Fernweiterleitung zuzulassen nur weiterleiten. Der Standardwert ist "Ja".

— Bart Polot

verwandt (falsch): serverfault.com/a/24389/328011

— YSC

Ich hatte eine Ursache für die Namensauflösung für diesen Fehler. Meine / etc / hosts hatten eine fehlerhafte IP-Adresse für den Namen des Servers (nicht für localhost), wie folgt:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Die konfigurierte Server-IP (und der mit den Host- / Dig-Befehlen aufgelöste DNS-Name) war jedoch 192.168.2.47. Ein einfacher Tippfehler, der durch eine vorherige IP-Neukonfiguration verursacht wurde. Nach dem Reparieren von / etc / hosts funktionierte die Tunnelverbindung einwandfrei:

ssh user@server.domain.com -L 3456:127.0.0.1:5901

Es ist seltsam, dass die echte IP den Fehler verursacht hat, als ich die Localhost-Literal-IP für den Tunnel verwendet habe. Distribution: Ubuntu 16.04 LTS.

— Fjor
quelle