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

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?

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.

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.

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

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 ...

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.

"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.

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.

Dies geschieht auch , wenn /etc/sshd_confighat

AllowTcpForwarding no 

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

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

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).

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.

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)"

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.

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 user@example.com: 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).

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.

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.

Ü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).

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.

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 user@127.0.0.1 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

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.

Ü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

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.

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)

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

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 user@server.domain.com -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.

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 :)

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