Erreur de tunneling SSH: «canal 1: échec de l'ouverture: interdiction administrative: échec de l'ouverture»

Quand j'ouvre ce tunnel ssh:

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

Je reçois cette erreur en essayant d'accéder au serveur HTTP s'exécutant sur localhost: 8984:

channel 1: open failed: administratively prohibited: open failed

Que signifie cette erreur et sur quelle machine pouvez-vous résoudre le problème?

canal 1: échec de l'ouverture: interdiction administrative: échec de l'ouverture

Le message ci-dessus indique que votre serveur SSH refuse la demande de votre client SSH d'ouvrir un canal latéral. Cela provient généralement de -D, -Lou -wcomme des canaux distincts dans le flux SSH sont nécessaires pour acheminer les données transférées.

Puisque vous utilisez -L(également applicable à -D), il y a deux options en question qui entraînent le rejet de cette demande par votre serveur SSH:

• AllowTcpForwarding (comme Steve Buzonas l'a mentionné)
• PermitOpen

Ces options peuvent être trouvées dans /etc/ssh/sshd_config. Vous devez vous assurer que:

• AllowTCPForwarding est soit absent, soit commenté, soit réglé sur yes
• PermitOpenn'est pas présent, est mis en commentaire ou est défini sur any[1]

De plus, si vous utilisez une clé SSH pour vous connecter, vous devez vérifier que l'entrée correspondant à votre clé SSH ~/.ssh/authorized_keysn'a pas de déclaration no-port-forwardingou permitopen[2].

PermitTunnelSi vous essayez d'utiliser l'option -w, l'option n'est pas pertinente pour votre commande, mais également pour ce sujet .

[1] Syntaxe complète dans la sshd_config(5)page de manuel.

[2] Syntaxe complète dans la authorized_keys(5)page de manuel.

Dans un cas très étrange, j'ai également rencontré cette erreur en essayant de créer un tunnel local. Ma commande était quelque chose comme ça:

ssh -L 1234:localhost:1234 user@remote

Le problème était que, sur l'hôte distant, /etc/hostsil n'y avait pas d'entrée pour "localhost", le serveur ssh ne savait donc pas comment configurer le tunnel. Un message d'erreur très hostile pour ce cas; content d'avoir enfin compris.

La leçon: assurez-vous que le nom d'hôte cible de votre tunnel peut être résolu par l'hôte distant, via DNS ou /etc/hosts.

Au moins une réponse est que la machine "distante" est inaccessible avec ssh pour une raison quelconque. Le message d'erreur est simplement absurde.

Si le 'distant' ne peut pas être résolu sur le serveur, vous obtiendrez cette erreur. Remplacez par une adresse IP et voyez si cela résout votre problème ...

(Fondamentalement la même réponse que celle de Neil - mais j'ai certainement trouvé que c'était là le problème de mon côté) [J'avais un pseudonyme pour le nom de la machine dans mon ~/.ssh/configfichier - et la machine distante ne savait rien de ce pseudonyme ...

Cette erreur apparaît définitivement lorsque vous utilisez les options ssh ControlPathet ControlMasterlors du partage d'une connexion de socket à réutiliser entre plusieurs connexions client (d'un client au même utilisateur @ serveur). En ouvrant trop (quoi que cela signifie, dans mon cas, environ 20 connexions), vous obtiendrez ce message. Fermer toutes les connexions précédentes me permet d’ouvrir plus récemment, encore une fois jusqu’à la limite.

"interdit par l'administration" est un indicateur de message ICMP spécifique qui se résume à "L'administrateur souhaite explicitement que cette connexion soit bloquée".

Vérifiez vos paramètres iptables.

Un problème similaire

Une autre piste possible

J'ai eu le même problème en utilisant ~/.ssh/authorized_keysavec permitopen.

Pour autosshcréer un tunnel, il me faut deux ports:

• un pour la connexion (10000),
• un pour la surveillance (10001).

Côté client

Cela m'a donné un problème similaire avec le port de surveillance:

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

J'ai eu ce message (après 10 minutes):

channel 2: open failed: administratively prohibited: open failed

Côté distant

Mon /var/log/auth.logcontenu:

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

Dans mon ~/.ssh/authorized_keys(côté distant) j'avais ceci:

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

Comment le résoudre

J'ai résolu ce problème en remplaçant les localhostinstances par 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...

Il semble que SSH ne comprenne pas que localhostc’est un raccourci vers 127.0.0.1, d’où le message dans auth.loget le message interdit par l’ administration .

Ce que je comprends ici est que cela signifie administrativement "en raison d’une configuration spécifique côté serveur".

Cela arrive aussi quand /etc/sshd_configa

AllowTcpForwarding no 

ensemble. Basculez-le sur yespour autoriser le transfert TCP.

Dans mon cas, j'ai dû remplacer localhostpar 127.0.0.1:

ssh -L 1234:localhost:3389 user@remote

pour le faire fonctionner.

J'essayais de rdesktop -L localhost:1234suivre les instructions d'Amazon sur la connexion à AWS EC2 via le tunneling SSH . J'avais essayé de changer /etc/ssh/sshd_config(le client et le serveur exécutent Ubuntu 16.04 LTS) par la réponse la plus votée. J'ai également vérifié qu'il localhostest des /etc/hostsdeux côtés.

Rien n'a fonctionné jusqu'à ce que je modifie la sshcommande elle-même en:

ssh -L 1234:127.0.0.1:3389 user@remote

Une certaine activité de dépannage est nécessaire pour trouver une réponse définitive:

• vérifier que la redirection de port est activée dans la configuration ssh de l'utilisateur,
• active la verbosité de ssh (-v),
• vérifier les journaux ssh sur l'hôte local et sécuriser les journaux sur celui distant,
• tester différents ports distants,
• vérifiez vos paramètres iptables (comme dit Shadur).

J'ai eu cette erreur une fois pour avoir mis la télécommande dans le paramètre -L, la 0.0.0.0 étant redondante, vous pouvez l'omettre avec les mêmes résultats, et je pense que vous devriez ajouter la -g pour que cela fonctionne.

C'est la ligne que j'utilise pour la tunnellisation: 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.

Cela peut également être causé par l'impossibilité de se connecter au port du côté local.

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

Cette commande tente de lier un port d'écoute 1234 sur la machine locale, qui mappe à un service sur le port 5678 sur une machine distante.

Si le port 1234 de la machine locale est déjà utilisé par un autre processus (par exemple une session ssh -f en arrière-plan), ssh ne pourra pas l'écouter sur ce port et le tunnel échouera.

Le problème est que ce message d'erreur peut signifier plusieurs choses, et "interdit par l'administration" donne parfois une idée fausse. Ainsi, en plus de vérifier le DNS, les pare-feu entre local et distant et sshd_config, vérifiez si le port local est déjà utilisé. Utilisation

lsof -ti:1234

pour savoir quel processus est en cours d'exécution sur 1234. Vous aurez peut-être besoin de sudo for lsof pour répertorier les processus détenus par d'autres utilisateurs. Ensuite, vous pouvez utiliser

ps aux | grep <pid>

pour savoir ce que ce processus est.

Pour obtenir tout cela en une seule commande:

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

J'ai eu le même message en essayant de tunnel. Il y avait un problème avec le serveur DNS du côté distant. Le problème a été résolu quand il est revenu au travail.

Je suis extrêmement surpris que personne n'ait mentionné qu'il pourrait s'agir d'un problème de DNS.

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)

Cela peut être présenté si la remoterésolution n'est pas possible ou si vous avez entré une syntaxe inconnue, comme c'est le cas ici, où j'ai ajouté un élément user@à la logique de transfert de port (qui ne fonctionnera pas).

Dans mon cas, le problème était dû à la demande d'un tunnel sans accès au shell alors que le serveur visait à imposer un changement de mot de passe sur mon compte. En raison de l'absence d'un shell, je ne pouvais pas voir cela et j'ai seulement reçu l'erreur

channel 2: open failed: administratively prohibited: open failed  

Ma configuration de tunnel était la suivante:

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

L'erreur affichée lors de la connexion directe au serveur (sans -N -f):

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

J'ai résolu le problème en me connectant avec l'accès au shell et en changeant le mot de passe. Ensuite, je pourrais simplement utiliser des tunnels sans accès shell à nouveau.

J'ai eu ce problème lors de la tentative de connexion via SSH avec un utilisateur uniquement autorisé à se connecter via SFTP.

Par exemple, c'était dans le serveur /etc/ssh/sshd_config:

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

Donc, dans ce cas, pour utiliser SSH, vous devrez soit supprimer l'utilisateur du sftponlygroupe équivalent , soit vous connecter en utilisant un utilisateur qui n'est pas limité à SFTP.

Vérifiez si /etc/resolv.confest vide sur le serveur sshauquel vous vous connectez. Plusieurs fois, j'ai trouvé qu'il s'agissait d'un /etc/resolv.conffichier vide .

S'il n'est pas root, vous pouvez simplement vérifier sur le serveur en essayant un pingou telnet80 () sur un nom d'hôte public, c'est-à-dire:

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

Après avoir ajouté les enregistrements du serveur de noms à /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

Cependant, vous devez également vérifier pourquoi /etc/resolv.confétait vide (le cas échéant, le client DHCP sur le serveur contient les enregistrements de serveur de noms).

Je recevais le même message lorsque SSH accordait Debian. Il s'est avéré que le système distant n'avait pas d'espace libre. Après avoir libéré de l'espace disque et redémarré, le tunnel a commencé à fonctionner.

J'ai vu cette erreur sur cygwin et cela devrait être vrai de linux aussi et a fonctionné pour moi. Dans mon cas, j’avais fait ssh -ND *: 1234 user@127.0.0.1 et lorsque j’ai connecté un navigateur à ce serveur comp-socks, il a parcouru, mais sur la comp où j’ai exécuté cette commande ssh, cette erreur s’affiche: la console avec chaque demande - pour un site au moins, bien que le navigateur l’ait récupérée via le proxy ou semblait le faire, du moins dans la mesure où j’ai vu l’âge principal. Mais ce changement a permis d'éliminer le message manquant.

http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-failed-administrative-prohibited-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

Un autre scénario est que le service auquel vous essayez d'accéder ne fonctionne pas. L’autre jour, j’ai rencontré ce problème et je me suis souvenu que l’instance httpd à laquelle je tentais de me connecter avait été arrêtée.

Pour résoudre le problème, commencez par le plus simple, qui consiste à vous connecter à l’autre ordinateur et à déterminer si vous pouvez vous connecter localement, puis vous rapprocher de votre ordinateur client. Au moins, cela vous permettra de déterminer à quel point la communication n’est pas en cours. Vous pouvez prendre d'autres approches, mais c'est celle qui a fonctionné pour moi.

Vérifiez votre routeur pour la protection DNS Rebinding . Mon routeur (pfsense) a la protection de réattribution DNS activée par défaut. Cela causait l'erreur «canal ouvert: échec interdit par l'administration: ouverture échouée» avec SSH

J'ai eu le même problème et j'ai réalisé que c'était DNS. Le trafic est tunnellisé mais la requête DNS no. Essayez de modifier manuellement votre fichier d'hôtes DNS et ajoutez le service auquel vous souhaitez accéder.

Mon cas:

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

J'ai eu cette erreur en écrivant cette entrée dans mon blog :

/etc/ssh/sshd_config avait quelque chose comme:

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

Mais ~/.ssh/configavait:

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

Notez la différence en cas (capitalisation) entre SSHBeyondRemote.server.com:22 et sshbeyondremote.server.com:22 .

Une fois le cas résolu, je ne voyais plus le problème.

J'utilisais:

Version du client OpenSSH:

• OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 mars 2016

Version du serveur OpenSSH:

• OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2n 7 décembre 2017

Autre cause de résolution de nom: Mon / etc / hosts avait une adresse IP erronée pour le nom du serveur (pas pour localhost), comme ceci:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Mais l'adresse IP du serveur configuré (et le nom DNS résolu avec les commandes host / dig) était 192.168.2.47. Une simple faute de frappe provoquée par une reconfiguration IP précédente. Après avoir corrigé / etc / hosts, la connexion du tunnel a parfaitement fonctionné:

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

Il est étrange que l’adresse IP réelle ait causé l’échec lorsque j’utilisais l’adresse IP littérale localhost pour le tunnel. Distro: Ubuntu 16.04 LTS.

La raison pour laquelle j’ai eu ce message n’est pas la plus courante, mais il vaut la peine de la mentionner. J'avais généré par script une liste de tunnels, et pour assurer une présentation en colonne, j'avais imprimé chaque dernier octet sur deux octets. Lorsque j'ai essayé d'ouvrir le transfert de tunnel vers 192.168.66.08, il a toujours échoué, car "08" est interprété par gethostbyaddr comme un nombre octal non valide :)

Il semble y avoir beaucoup de causes profondes possibles pour ce message. Dans mon cas, c’était une impossibilité d’accéder à la télécommande car je n’avais pas fourni le fichier de clé correctement.

le -L option ajoute un saut SSH implicite (en utilisant efficacement l'hôte SSH explicite en tant que serveur de bastion / saut). Il peut être plus facile de résoudre ce problème en effectuant le saut de manière explicite et en créant un shell de connexion sur la machine cible à l’aide de "proxycommand".

Une fois que cela fonctionne, vous pouvez transférer le port en fonction de la machine cible localhost(en supposant qu'elle puisse se connecter à elle-même):

-N -L 1234:localhost:1234