SSH-Tunneling-Fehler: "Kanal 1: Öffnen fehlgeschlagen: Administrativ verboten: Öffnen fehlgeschlagen"

184

Wenn ich diesen SSH-Tunnel öffne:

ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983

Ich erhalte diesen Fehler, wenn ich versuche, auf den HTTP-Server zuzugreifen, der auf localhost ausgeführt wird: 8984:

channel 1: open failed: administratively prohibited: open failed

Was bedeutet dieser Fehler und auf welchem ​​Computer können Sie das Problem beheben?

Neil
quelle
Vielleicht fehlt mir etwas, aber warum versuchen Sie, mit einem ssh-Client auf einen Webserver zuzugreifen?
Faheem Mitha
Warum leiten Sie X11 (Option -X) hier weiter? Wenn Sie nur HTTP weiterleiten möchten, ist dies nicht erforderlich. Und als Randnotiz könnte IMHO ssh die falsche Lösung sein, um einen Webserver auf mehreren Ports verfügbar zu machen.
Marcel G
29
Ich habe festgestellt, dass dies remotein meinem Fall " Hostname kann nicht aufgelöst werden " bedeutet.
RobM
3
Wie Sie aus dem Dutzend Antworten unten ersehen können, sollte die Fehlermeldung, obwohl sie sehr spezifisch aussieht, als allgemeiner Fehler verstanden werden. Im Allgemeinen besteht die Lösung darin, eine Shell auf der Fernbedienung zu öffnen und dieselbe Verbindung herzustellen, um die tatsächliche Ursache zu ermitteln. Unter Antworten finden Sie die häufigsten tatsächlichen Ursachen.
Stéphane Gourichon
Ein DNS - Auflösungsfehler kann diesen Fehler verursachen und die Verbindung gefrieren kann , bis es mal aus: superuser.com/a/700677
user423430

Antworten:

122

Kanal 1: Öffnen fehlgeschlagen: Administrativ verboten: Öffnen fehlgeschlagen

Die obige Meldung bezieht sich darauf, dass Ihr SSH-Server die Anfrage Ihres SSH-Clients zum Öffnen eines Seitenkanals ablehnt. Dies kommt in der Regel aus -D, -Loder -wals getrennte Kanäle in dem SSH Strom über die übermittelten Daten zur Fähre erforderlich.

Da Sie -L(auch für -D) verwenden, gibt es zwei in Frage kommende Optionen, die Ihren SSH-Server veranlassen, diese Anfrage abzulehnen:

  • AllowTcpForwarding (wie Steve Buzonas erwähnte)
  • PermitOpen

Diese Optionen finden Sie in /etc/ssh/sshd_config. Sie sollten sicherstellen, dass:

  • AllowTCPForwarding ist entweder nicht vorhanden, ist auskommentiert oder auf gesetzt yes
  • PermitOpenist entweder nicht vorhanden, auskommentiert oder auf any[1] gesetzt

Wenn Sie einen SSH-Schlüssel zum Herstellen einer Verbindung verwenden, sollten Sie außerdem überprüfen, ob der Ihrem SSH-Schlüssel entsprechende Eintrag ~/.ssh/authorized_keyskeine Anweisungen no-port-forwardingoder enthält permitopen[2].

PermitTunnelWenn Sie versuchen, die Option -w zu verwenden , ist diese Option für Ihren Befehl nicht relevant, aber auch für dieses Thema nicht relevant .

[1] Vollständige Syntax in der sshd_config(5)Manpage.

[2] Vollständige Syntax in der authorized_keys(5)Manpage.

hyperair
quelle
Hier, was ich speziell in sshd_config hinzufüge, damit es funktioniert: TCPKeepAlive yes AllowTCPForwarding yes PermitOpen any Ich habe ein paar "open failed", aber es scheint eine normale Sache zu sein. Die Dinge funktionieren sehr gut.
Pierre Thibault
4
Zu beachtender Eckfall: Sie können diesen Fehler erhalten, wenn Sie versuchen, ein Tap / Tun-Gerät mit SSH zu erstellen, und SSH lässt dies zu, der Kernel jedoch nicht. Dies kann in LXC-Containern auftreten. Siehe blog.felixbrucker.com/2015/10/01/... für die genauen Details, aber in diesem Fall , dass Sie möchten hinzufügen , lxc.cgroup.devices.allow = c 10:200 rwmum Ihre Container config, und stellen Sie sicher , dass , wenn /dev/net/tunnicht vorhanden ist , wird mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tunbeim Booten in den Behälter geleitet wird.
Azendale
@ Azendale, das ist interessant, danke. Gibt es genau die gleiche Fehlermeldung oder etwas anderes?
Hyperair
1
@ St.Antario AllowTcpForwardingermöglicht es Ihnen, TCP-Ports über SSH weiterzuleiten, was der -L 0.0.0.0:8984:remote:8983Parameter anfordert. Wenn auf AllowTcpForwardinggesetzt no, lehnt SSH die Portweiterleitungsanforderung ab, sodass dieser Fehler angezeigt wird.
Hyperair
2
Versucht, den Großbuchstaben von AllowTCPForwardingbis zu bearbeiten AllowTcpForwarding, aber SE möchte, dass mindestens 6 Zeichen geändert werden. Ich stelle nur fest, dass der richtige Fall die TcpVersion ist, die beim ersten Mal richtig verwendet wurde.
Dbreaux
51

In einem sehr seltsamen Fall trat dieser Fehler auch beim Erstellen eines lokalen Tunnels auf. Mein Befehl lautete ungefähr so:

ssh -L 1234:localhost:1234 user@remote

Das Problem bestand darin, dass auf dem Remote-Host /etc/hostskein Eintrag für "localhost" vorhanden war, sodass der SSH-Server nicht wusste, wie der Tunnel eingerichtet werden sollte. Eine sehr unfreundliche Fehlermeldung für diesen Fall; froh, dass ich es endlich herausgefunden habe.

Die Lektion: Stellen Sie sicher, dass der Ziel-Hostname Ihres Tunnels vom Remote-Host entweder über DNS oder auflösbar ist /etc/hosts.

Cobbzilla
quelle
2
Danke, das war das Problem für mich. Ich habe den Hostnamen für die IP lokal erstellt, aber nicht auf dem Remote-SSH-Server.
dev_feed
2
"Der Ziel-Hostname Ihres Tunnels" ist etwas schwer zu entziffern. Können Sie ein konkretes praktikables Beispiel geben, mit dem ich Ihr Beispiel nehmen und den "Ziel-Hostnamen" in Ihrem Beispiel durch meinen Ziel-Hostnamen ersetzen kann (sobald ich verstanden habe, was Sie damit meinen) und das funktioniert?
Terrence Brannon
1
Ich bin mir nicht mal sicher, ob dein Kommentar Sinn macht. Sie sagen, dass der Remotecomputer keinen Eintrag für localhost hatte. Aber dann sagen , dass der Remote - Host die lösen müssen Zielhostnamen nicht den lokalen Hostnamen. Auch hier wäre ein ganz konkretes Beispiel der Situation vorher und nachher hilfreich.
Terrence Brannon
1
@TerrenceBrannon im obigen Befehl ist "localhost" der Zielhostname des Tunnels . Beim Erstellen eines SSH-Tunnels meldet sich der Befehl ssh zuerst beim fernen System an ( user@remote) und richtet dann vom fernen Ende aus Tunnel zu den aufgeführten Zielhosts ein (dies ist im obigen Befehl der Fall localhost). Dabei wird das Auflösungsschema für Hostnamen auf dem Remote- Host verwendet. Wenn sich der Computer, auf dem Sie SSH installiert haben, nicht auflösen lässt localhost, wird diese Fehlermeldung angezeigt .
Cobbzilla
1
In meinem Fall war es so einfach, als hätte ich den Hostnamen des Ziels falsch eingegeben, was sich natürlich nicht auflöste, aber meine Augen sahen den Tippfehler viel zu lange nicht.
Randall
25

Mindestens eine Antwort ist, dass die Maschine "remote" mit ssh aus irgendeinem Grund nicht erreichbar ist. Die Fehlermeldung ist einfach nur absurd.

Neil
quelle
2
Nein, ist es nicht; Ich benutze icmp-admin-disabled als Ablehnungsflag in der Firewall-Konfiguration.
Shadur
9
+1, Die administrativ verbotene Nachricht lässt einen glauben, dass es sich um eine Firewall-Blockierung handelt. Sie erhalten jedoch dieselbe Nachricht, wenn keine Firewall-Blockierung vorliegt, das Öffnen jedoch fehlschlägt, da keine Route zum Remote-Host besteht.
Steve Buzonas
1
Ich habe gerade einige Minuten damit verbracht, diesem Problem nachzugehen, dessen Botschaft in meinem Kontext keinen Sinn ergibt. Zum Glück ist es beim Überprüfen der Protokolldateien der Mittelstation ziemlich klar.
Yaccz
Tatsächlich wird diese Fehlermeldung angezeigt, wenn "remote" nicht erreichbar ist - weil es offline ist, nicht existiert, der Hostname nicht aufgelöst wird.
Michael Martinez
18

Wenn das Problem auf dem Server nicht behoben werden kann, wird dieser Fehler angezeigt. Ersetzen Sie durch eine IP-Adresse und prüfen Sie, ob das Problem dadurch behoben wird ...

(Im Grunde genommen gleiche Antwort wie die von Neil - aber ich fand sicher , dass das Problem auf meiner Seite zu sein) [hatte ich einen Alias für die Computernamen in meiner ~/.ssh/configDatei - und der Remote - Computer wußte nichts von dieser Bezeichnung ...

jacquesjtheron
quelle
Möglicherweise wird der gleiche Fehler auch -Dangezeigt, wenn Sie (DynamicForward) als SOCKS-Proxy in einem Browser verwenden. Das heißt, der Versuch, auf eine Website zuzugreifen, die der Tunnel-Host nicht auflösen kann.
Timss
10

Dieser Fehler tritt definitiv auf, wenn Sie ssh-Optionen verwenden ControlPathund ControlMastereine Socket-Verbindung für mehrere Client-Verbindungen (von einem Client zu demselben Benutzer @ Server) freigeben. Wenn Sie zu viele öffnen (was auch immer das bedeutet, in meinem Fall ~ 20 Verbindungen), erhalten Sie diese Meldung. Wenn ich frühere Verbindungen schließe, öffne ich sie wieder bis zum Limit.

Matej Kovac
quelle
Ich bin hierher gekommen, um zu suchen, wo ich dieses ControlMaster-Multiplex-Limit einstellen kann. Wenn jemand es weiß, kann er es gerne teilen.
Clacke
1
Clacke: Laut bugs.debian.org/cgi-bin/bugreport.cgi?bug=546854 können Sie einen MaxSession-Parameter in der Datei / etc / ssh / sshd_config hinzufügen, um dies festzulegen. Laut Manpage ist dies standardmäßig auf 10 gesetzt.
Oliver
@oliver: Bestätigen, MaxSession funktioniert, danke. 64 auf meiner Arbeitsmappe bestoßen.
Matej Kovac
2
Seien Sie vorsichtig, es ist nicht MaxSessionaber MaxSessions. Zwar gibt es einige Schutzmechanismen sind, nicht brechen Ihre SSH - Server - Konfiguration ...
Stéphane Gourichon
8

"Administrativ verboten" ist ein bestimmtes ICMP-Nachrichtenflag, das sich auf "Der Administrator möchte ausdrücklich, dass diese Verbindung blockiert wird" beschränkt.

Überprüfen Sie Ihre Iptables-Einstellungen.

Shadur
quelle
5
Nicht unbedingt. Die Nachricht wird generiert, wenn der Host die Anforderung nicht bedienen kann. Dies liegt in der Regel daran, dass der Administrator die Verbindung blockiert hat. Es kann jedoch auch sein, dass die Verbindung nicht explizit blockiert ist, sondern keine Route zum gewünschten Host besteht. AFAIK sshhat keine Logik, um zu bestimmen, warum eine Verbindung fehlgeschlagen ist. Es wird lediglich davon ausgegangen, dass die Verbindung absichtlich blockiert wurde, wenn Sie versuchen, eine Verbindung herzustellen.
Steve Buzonas
2
Oh nein. Es gibt einen deutlichen Unterschied zwischen der Art der ICMP-Antwort "Keine Route zum Host" und der Antwort "Administrativ verboten". Wenn ein Router nicht absichtlich falsch konfiguriert wurde, bedeutet letztere genau das, was auf dem Bildschirm steht.
Shadur
1
Ich habe gerade "administrativ verboten", als ich einen Hostnamen verwendet habe, der nicht aufgelöst werden konnte. Es scheint also ein Allheilmittel zu sein. Vielleicht macht ssh eine Übersetzung?
Ganesh Sittampalam
5

Ein ähnliches Problem

Ein weiterer möglicher Hinweis

Ich hatte das gleiche Problem ~/.ssh/authorized_keysmit permitopen.

Da ich autossheinen Tunnel erstelle, benötige ich zwei Ports:

  • eine für den Anschluss (10000),
  • eine zur Überwachung (10001).

Auf Kundenseite

Dies gab mir ein ähnliches Problem mit dem Überwachungsport:

autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa user@remote

Ich hatte diese Nachricht (nach 10 Minuten):

channel 2: open failed: administratively prohibited: open failed

Auf der entfernten Seite

Meine /var/log/auth.logenthaltenen:

Received request to connect to host 127.0.0.1 port 10001, but the request was denied.

Auf meiner ~/.ssh/authorized_keys(entfernten) Seite hatte ich folgendes:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA...

Wie man es löst

Ich habe das gelöst, indem ich localhostInstanzen ersetzt habe durch 127.0.0.1:

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="127.0.0.1:10000",permitopen="127.0.0.1:10001" ssh-rsa AAAA...

Es scheint, dass SSH nicht versteht, dass dies localhosteine Verknüpfung ist 127.0.0.1, daher die Nachricht in auth.logund die administrativ verbotene Nachricht.

Was ich hier verstehe ist, dass administrativ "aufgrund einer bestimmten Konfiguration auf der Serverseite" bedeutet.

lauhub
quelle
localhost ist wahrscheinlich :: 1 (ipv6) zugeordnet, und Sie haben dort aus irgendeinem Grund nicht zugehört
Jo Rhett
4

Dies geschieht auch , wenn /etc/sshd_confighat

AllowTcpForwarding no 

einstellen. Aktivieren Sie diese Option, yesum die TCP-Weiterleitung zuzulassen.

user578125
quelle
4

In meinem Fall musste ich ersetzen localhostdurch 127.0.0.1:

ssh -L 1234:localhost:3389 user@remote

damit es funktioniert.

Ich habe versucht, rdesktop -L localhost:1234den Anweisungen von Amazon zum Herstellen einer Verbindung zu AWS EC2 über SSH-Tunneling zu folgen . Ich hatte versucht zu ändern /etc/ssh/sshd_config(sowohl Client als auch Server führen Ubuntu 16.04 LTS aus), je nach der am höchsten bewerteten Antwort. Ich habe auch überprüft, dass dies auf beiden Seiten der Fall localhostist /etc/hosts.

Nichts hat funktioniert, bis ich den sshBefehl selbst geändert habe:

ssh -L 1234:127.0.0.1:3389 user@remote
Tinlyx
quelle
Ich danke dir sehr!
Thibaut Barrère
3

Einige Schritte zur Fehlerbehebung sind erforderlich, um eine endgültige Antwort zu finden:

  • Überprüfen Sie, ob die Portweiterleitung in der SSH-Konfiguration des Benutzers aktiviert ist.
  • aktiviere die Ausführlichkeit von ssh (-v),
  • Überprüfen Sie SSH-Protokolle auf dem lokalen Host und sichere Protokolle auf dem Remote-Host.
  • teste verschiedene Remote Ports,
  • Überprüfen Sie Ihre Iptables-Einstellungen (wie Shadur sagte).
Marco Solieri
quelle
3

Ich habe diesen Fehler einmal erhalten, weil ich die Fernbedienung in den -L-Parameter gestellt habe. Auch die 0.0.0.0 ist überflüssig. Sie können sie mit denselben Ergebnissen weglassen, und ich denke, Sie sollten die -g hinzufügen, damit sie funktioniert.

Dies ist die Linie, die ich zum Tunneln benutze: ssh -L 8983:locahost:8984 user@remote -4 -g -N

-4 tells to use only ipv4
-g Allows remote hosts to connect to local forwarded ports.
-N Do not execute a remote command.  This is useful for just forwarding ports (protocol version 2 only). I use this to clog the terminal so I don't forget to close it since generally I need the tunnels temporarily.
Marciano
quelle
3

Dies kann auch dadurch verursacht werden, dass keine Bindung zum Port auf der lokalen Seite möglich ist.

ssh -Nn -L 1234:remote:5678 user@remote

Dieser Befehl versucht, einen Überwachungsport 1234 auf dem lokalen Computer zu binden, der einem Dienst auf Port 5678 auf einem Remotecomputer zugeordnet ist.

Wenn Port 1234 auf dem lokalen Computer bereits von einem anderen Prozess verwendet wird (möglicherweise eine ssh -f-Sitzung im Hintergrund), kann ssh diesen Port nicht überwachen, und der Tunnel schlägt fehl.

Das Problem ist, dass diese Fehlermeldung mehrere Bedeutungen haben kann und "administrativ verboten" manchmal die falsche Vorstellung vermittelt. Überprüfen Sie also zusätzlich zur Überprüfung von DNS, Firewalls zwischen lokal und remote und sshd_config, ob der lokale Port bereits verwendet wird. Verwenden

lsof -ti:1234

Möglicherweise benötigen Sie sudo, damit lsof Prozesse auflistet, die anderen Benutzern gehören. Dann können Sie verwenden

ps aux | grep <pid>

herauszufinden, was dieser Prozess ist.

Um dies alles in einem Befehl zu bekommen:

ps aux | grep "$(sudo lsof -ti:1234)"
Mnebuerquo
quelle
2

Ich hatte die gleiche Nachricht beim Versuch zu tunneln. Es gab ein Problem mit dem DNS-Server auf der Remote-Seite. Das Problem wurde gelöst, als es wieder funktionierte.

Leonardo Brunnet
quelle
2

Ich bin sehr überrascht, dass niemand erwähnt hat, dass dies ein DNS-Problem sein könnte.

journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to [email protected]: unknown host (Name or service not known)

Dies wird möglicherweise angezeigt, wenn remotees nicht auflösbar ist oder Sie eine unbekannte Syntax eingegeben haben, wie hier, wo ich user@der Port-Forward-Logik ein hinzugefügt habe (was nicht funktioniert).

Torxed
quelle
2

In meinem Fall lag das Problem daran, dass ein Tunnel ohne Shell-Zugriff angefordert wurde, während der Server eine Kennwortänderung für mein Konto erzwingen wollte. Aufgrund des Fehlens einer Shell konnte ich das nicht sehen und erhielt nur den Fehler

channel 2: open failed: administratively prohibited: open failed  

Meine Tunnelkonfiguration war wie folgt:

ssh -p [ssh-port] -N -f -L [local-port]:127.0.0.1:[remote-port]
[server-address]

Der Fehler wurde beim Anmelden direkt am Server angezeigt (ohne -N -f):

WARNING: Your password has expired. You must change your password now
and login again!

Ich habe das Problem behoben, indem ich mich mit Shell-Zugriff angemeldet und das Passwort geändert habe. Dann könnte ich einfach wieder Tunnel ohne Shell-Zugang benutzen.

Pieter Van Gorp
quelle
1

Ich hatte dieses Problem beim Versuch, eine Verbindung über SSH mit einem Benutzer herzustellen, der nur über SFTP eine Verbindung herstellen durfte.

Dies war zum Beispiel im Server /etc/ssh/sshd_config:

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /usr/chroot/%u
    [...]
Match

In diesem Fall müssen Sie zur Verwendung von SSH entweder den Benutzer aus der entsprechenden sftponlyGruppe entfernen oder eine Verbindung mit einem Benutzer herstellen, der nicht auf SFTP beschränkt ist.

Mike
quelle
1

Überprüfen Sie, ob /etc/resolv.confauf dem Server, zu dem Sie gehen ssh, noch etwas frei ist. Ich habe mehrmals festgestellt, dass dies mit einer leeren /etc/resolv.confDatei zusammenhängt

Wenn Sie kein root-Benutzer sind, können Sie den Server einfach überprüfen, indem Sie some pingoder telnet(80) auf einem öffentlichen Hostnamen versuchen , dh:

root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

Nach dem Hinzufügen von Nameserver-Einträgen zu /etc/resolv.conf:

root@bananapi ~ # telnet www.google.com 80
Trying 74.125.195.104...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 302 Found
Location: http://www.google.ro/?gws_rd=cr&ei=8fStVZ-hMIv6UvX6iuAK

Sie sollten jedoch auch überprüfen, warum /etc/resolv.confleer war (dies wird normalerweise vom DHCP-Client auf dem Server mit Nameserver-Einträgen gefüllt, falls zutreffend).

Ender
quelle
1

Ich habe die gleiche Nachricht erhalten, als SSH auf Debian umgestellt hat. Es stellte sich heraus, dass das Remote-System keinen freien Speicherplatz hatte. Nachdem Speicherplatz freigegeben und der Tunnel neu gestartet wurde, begann er zu arbeiten.

SlavaSt
quelle
0

Ich habe diesen Fehler auf Cygwin gesehen und das sollte auch für Linux gelten und hat für mich funktioniert. In meinem Fall hatte ich ssh -ND *: 1234 [email protected] ausgeführt, und als ich einen Browser mit diesem Comp-Socks-Server verband, wurde dieser durchsucht, aber auf dem Comp, auf dem ich den Befehl ssh ausgeführt habe, wurde dieser Fehler angezeigt die Konsole bei jeder Anfrage - für mindestens eine Site, obwohl der Browser sie über den Proxy abgerufen hat oder zumindest in dem Maße schien, als ich das Hauptalter sah. Durch diese Änderung wurde jedoch die fehlgeschlagene Nachricht entfernt

http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-failed-administrativ-verboten-open-failed/

While trying to do some SSH tunneling, here is the error I got :
channel 3: open failed: administratively prohibited: open failed
To avoid this kind of error, have a look at the SSH daemon configuration file :
/etc/ssh/sshd_config
Add possibly the following line :
root@remote-server:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
root@remote-server:~# service ssh restart
or

root@remote-server:~# /etc/init.d/ssh restart
barlop
quelle
Das AFAIK-Tunneln ist standardmäßig aktiviert, da durch das Deaktivieren keine Sicherheitsebene hinzugefügt wird. Dies ist in erster Linie ein Nachteil beim Hinzufügen eines Tunnels eines Drittanbieters. Ich habe ein ähnliches Problem beim Versuch, einen Proxy für interne Server von einem externen Standort aus zu erstellen, und das Tunneln ist aktiviert ACCEPT.
Steve Buzonas
@SteveBuzonas Ich sehe dies in / etc / sshd_config, damit a) das Tunneln nicht deaktiviert wird. B) Was meine Antwort betrifft, ist die Lösung möglicherweise keine gute Idee. Folgendes sagt sshd_config zu dieser Option: # Um getunnelte Klartext-Passwörter zu deaktivieren, ändern Sie hier den Wert auf no! #PermitTunnel no
barlop
@SteveBuzonas Aktivieren Sie das Kontrollkästchen "Nein". Sie können tunneln, da das Tunneln standardmäßig aktiviert ist.
Barlop
Ich habe darüber nachgedacht: AllowTCPForwardingDer Kommentar, über den Sie sprechen, # To disable tunneled clear textbezieht sich auf PasswordAuthenticationdie Einstellung "Nein". Hierbei handelt es sich um PermitTunneleine Einstellung, mit der Layer 2- oder Layer 3-Netzwerktunnel über "Tun / Tap" zugelassen werden. Die Standardeinstellung lautet "Nein". Die Optionen L, R und D verwenden die TCP-Weiterleitung und kein Gerät zum Tunneln.
Steve Buzonas
0

Ein weiteres Szenario ist, dass der Dienst, auf den Sie zugreifen möchten, nicht ausgeführt wird. Ich bin neulich auf dieses Problem gestoßen, nur um mich daran zu erinnern, dass die httpd-Instanz, mit der ich mich verbinden wollte, gestoppt wurde.

Ihre Schritte zur Lösung des Problems wären, mit dem einfachsten zu beginnen, nämlich zu dem anderen Computer zu gehen und zu prüfen, ob Sie eine lokale Verbindung herstellen und sich dann wieder auf Ihren Clientcomputer hinarbeiten können. Zumindest können Sie so herausfinden, an welchem ​​Punkt die Kommunikation nicht stattfindet. Sie können auch andere Ansätze wählen, aber diese haben bei mir funktioniert.

Andre M
quelle
Ein nützlicher allgemeiner Tipp, aber keine Antwort auf die gestellte Frage.
Kyle Jones
0

Überprüfen Sie Ihren Router auf DNS-Rebinding- Schutz. Auf meinem Router (pfsense) ist der DNS-Rebinding-Schutz standardmäßig aktiviert. Es verursachte den Fehler "Kanal offen: fehlgeschlagen, administrativ verboten: Öffnen fehlgeschlagen" mit SSH

Effekt
quelle
0

Ich hatte das gleiche Problem und mir wurde klar, dass es sich um DNS handelte. Der Datenverkehr wird getunnelt, aber die DNS-Anforderungsnr. Versuchen Sie, die DNS-Hosts-Datei manuell zu bearbeiten und den Dienst hinzuzufügen, auf den Sie zugreifen möchten.

Daten
quelle
0

Mein Fall:

$ssh -D 8081 localhost >>log1.txt 2>&1 &

----wait for 3 days

$tail -f log1.txt
channel 963: open failed: connect failed: Connection refused
channel 963: open failed: connect failed: Connection refused
channel 971: open failed: connect failed: Connection reset by peer
channel 982: open failed: connect failed: Connection timed out
channel 979: open failed: connect failed: Connection timed out
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed

$ps  axu | grep 8081
root       404  0.0  0.0   4244   592 pts/1    S+   05:44   0:00 grep --color=auto 8081
root       807  0.3  0.6   8596  6192 ?        S    Mar17  76:44 ssh -D 8081 localhost

$lsof -p 807 | grep TCP
ssh     807 root 1013u  sock     0,8      0t0 2076902 protocol: TCP
ssh     807 root 1014u  sock     0,8      0t0 2078751 protocol: TCP
ssh     807 root 1015u  sock     0,8      0t0 2076894 protocol: TCP
.....

$lsof -p 807 | wc -l
1047

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   malcolm-desktop

$ssh localhost
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic i686)

----after restart ssh -D 8081 localhost
$ lsof -p 1184 | grep TCP
ssh     1184 root    3u  IPv4 2332193      0t0   TCP localhost:37742->localhost:ssh (ESTABLISHED)
ssh     1184 root    4u  IPv6 2332197      0t0   TCP ip6-localhost:tproxy (LISTEN)
ssh     1184 root    5u  IPv4 2332198      0t0   TCP localhost:tproxy (LISTEN)
ssh     1184 root    6u  IPv4 2332215      0t0   TCP localhost:tproxy->localhost:60136 (ESTABLISHED)
ssh     1184 root    7u  IPv4 2336142      0t0   TCP localhost:tproxy->localhost:32928 (CLOSE_WAIT)
ssh     1184 root    8u  IPv4 2336062      0t0   TCP localhost:tproxy->localhost:32880 (CLOSE_WAIT)
Diyismus
quelle
0

Ich habe diesen Fehler beim Schreiben dieses Eintrags in meinem Blog erhalten :

/etc/ssh/sshd_config hatte so etwas wie:

Match Group SSHTunnel_RemoteAccessGroup
    AllowTcpForwarding yes
    PermitOpen=sshbeyondremote.server.com:22

Aber ~/.ssh/confighatte:

Host remote.server.com
  HostName remote.server.com
  Port 10022
  User useronremote
  IdentityFile ~/.ssh/keys/key1/openssh.keyforremote.priv
  LocalForward 2222 SSHBeyondRemote.server.com:22

Beachten Sie den Unterschied in Fall (Großschreibung ) zwischen SSHBeyondRemote.server.com:22 und sshbeyondremote.server.com:22 .

Nachdem ich den Fall behoben hatte, sah ich das Problem nicht mehr.

Ich habe benutzt:

Version des OpenSSH-Clients:

  • OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1. März 2016

Version des OpenSSH-Servers:

  • OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2n 7. Dezember 2017
Zach Pfeffer
quelle
1
Wenn Sie auf etwas verlinken, für etwas werben, es zitieren oder anderweitig auf etwas verweisen, mit dem Sie verbunden sind, müssen Sie diese Zugehörigkeit ausdrücklich offenlegen. '' Beim Zusammenstellen (Link) '' zu sagen ist nicht genug (weil ich nicht verstanden habe, was es bedeutet, bis ich herausgefunden habe, dass Sie auf Ihren eigenen Blog verlinken); Es reicht nicht aus, eine URL zu haben, die Ihrem Stack Exchange-Benutzernamen entspricht. Referenzen: Wie man kein Spammer ist ,  Vermeiden Sie offene Eigenwerbung ,… (Fortsetzung)
Scott
(Fortsetzung)… und wann sollten wir die Zugehörigkeitspflicht durchsetzen?    Es steht Ihnen frei, Ihren Blog, Ihren Arbeitgeber, jede bekannte Software, die Sie entwickelt haben, alle Bücher, die Sie geschrieben haben, alle anderen Projekte, mit denen Sie verbunden sind oder waren, usw. auf Ihrer Benutzerprofilseite zu erwähnen .
Scott
0

Anderer Grund für die Namensauflösung: Meine / etc / hosts hatte eine falsche 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 Befehlen host / dig aufgelöste DNS-Name) lautete 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 [email protected] -L 3456:127.0.0.1:5901

Es ist seltsam, dass die reale IP den Fehler verursachte, als ich die localhost-Literal-IP für den Tunnel verwendete. Distribution: Ubuntu 16.04 LTS.

Fjor
quelle
0

Der Grund, warum ich diese Nachricht hatte, ist nicht der häufigste, aber es lohnt sich zu erwähnen. Ich hatte per Skript eine Liste von Tunneln erzeugt und um eine Spaltenpräsentation zu gewährleisten, hatte ich jedes letzte Byte auf zwei Bytes gedruckt. Wenn ich versuchte, die Tunnelweiterleitung auf 192.168.66.08 zu öffnen, schlug dies immer fehl, da '08' von gethostbyaddr als ungültige Oktalzahl interpretiert wird :)

Philippe De Muyter
quelle
0

Es scheint, dass es viele mögliche Ursachen für diese Nachricht gibt. In meinem Fall konnte ich nicht auf die Fernbedienung zugreifen, da ich die Schlüsseldatei nicht korrekt angegeben hatte.

Die -LOption fügt einen impliziten SSH-Sprung hinzu (effektiv unter Verwendung des expliziten SSH-Hosts als Bastion / Jump-Server). Es kann einfacher sein, dies zu debuggen, indem Sie den Sprung explizit ausführen und mit "proxycommand" eine Anmeldeshell für den Zielcomputer erstellen.

Sobald dies funktioniert, können Sie den Port basierend auf dem Zielcomputer weiterleiten localhost(vorausgesetzt, er kann sich bei sich selbst anmelden):

-N -L 1234:localhost:1234
kein Balken
quelle