Erreur de tunnel SSH: "canal 1: échec d'ouverture: interdiction administrative: échec d'ouverture"
Quand j'ouvre ce tunnel ssh:
ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983
J'obtiens cette erreur en essayant d'accéder au serveur HTTP fonctionnant 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 d'ouverture: administrativement interdit: échec d'ouverture
Le message ci-dessus fait référence à votre serveur SSH rejetant la demande de votre client SSH d'ouvrir un canal latéral. Cela provient généralement de -D, -L Ou -w, Car des canaux distincts dans le flux SSH sont nécessaires pour transporter les données transmises.
Puisque vous utilisez -L (Également applicable à -D), Il existe deux options en question qui poussent votre serveur SSH à rejeter cette demande:
AllowTcpForwarding(comme Steve Buzonas l'a mentionné)PermitOpen
Ces options se trouvent dans /etc/ssh/sshd_config. Vous devez vous assurer que:
AllowTCPForwardingn'est pas présent, est mis en commentaire ou est défini suryesPermitOpenn'est pas présent, est mis en commentaire ou est défini surany[1]
De plus, si vous utilisez une clé SSH pour vous connecter, vous devez vérifier que l'entrée correspondant à votre clé SSH dans ~/.ssh/authorized_keys N'a pas d'instructions no-port-forwarding Ou permitopen [2] .
L'option PermitTunnel n'est pas pertinente pour votre commande particulière, mais est également pertinente pour cette rubrique si vous essayez d'utiliser l'option -w.
[1] Syntaxe complète dans la page de manuel sshd_config(5) .
[2] Syntaxe complète dans la page de manuel authorized_keys(5) .
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 ceci:
ssh -L 1234:localhost:1234 user@remote
Le problème était, sur l'hôte distant, /etc/hosts n'avait pas d'entrée pour "localhost" donc le serveur ssh ne savait pas comment configurer le tunnel. Un message d'erreur très hostile pour ce cas; heureux d'avoir enfin compris.
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 tout simplement absurde.
Si la "télécommande" ne peut pas être résolue sur le serveur, vous obtiendrez cette erreur. Remplacez par une adresse IP et voyez si cela résout votre problème ...
(Fondamentalement, même réponse que celle de Neil - mais j'ai certainement trouvé que c'était le problème de mon côté) [J'avais un alias pour le nom de la machine dans mon ~/.ssh/config fichier - et la machine distante ne savait rien de cet alias ...
Cette erreur apparaît définitivement lorsque vous utilisez les options ssh ControlPath et ControlMaster pour partager une connexion socket à réutiliser entre plusieurs connexions client (d'un client au même utilisateur @ serveur). L'ouverture d'un trop grand nombre (quoi que cela signifie, dans mon cas ~ 20 connexions) génère ce message. Fermer toutes les connexions précédentes me permet d'ouvrir de nouvelles connexions, encore une fois jusqu'à la limite.
"administrativement interdit" 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.
Dans mon cas, j'ai dû remplacer localhost par 127.0.0.1 dans:
ssh -L 1234:localhost:3389 user@remote
pour le faire fonctionner.
J'étais en train d'essayer de rdesktop -L localhost:1234 suivant Amazon instructions pour se connecter à 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) selon la réponse la plus élevée. J'ai également vérifié que localhost est dans /etc/hosts sur les deux côtés.
Rien n'a fonctionné jusqu'à ce que je change la commande ssh elle-même en:
ssh -L 1234:127.0.0.1:3389 user@remote
Un problème similaire
Une autre piste possible
J'ai eu le même problème en utilisant ~/.ssh/authorized_keys avec permitopen.
Comme j'utilise autossh pour créer un tunnel, j'ai besoin de deux ports:
- un pour la connexion (10000),
- une 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é éloigné
Ma /var/log/auth.log contenait:
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 instances de localhost 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 localhost est un raccourci vers 127.0.0.1, d'où le message dans auth.log et le message administrativement interdit.
Ce que je comprends ici, c'est que administrativement signifie "en raison d'une configuration spécifique côté serveur".
Cela se produit également lorsque /etc/sshd_config a
AllowTcpForwarding no
ensemble. Basculez-le sur yes pour autoriser TCP transfert.
J'ai eu cette erreur une fois pour avoir placé la télécommande dans le paramètre -L, le 0.0.0.0 est également redondant, vous pouvez l'omettre avec les mêmes résultats, et je pense que vous devriez ajouter le -g pour que cela fonctionne.
Voici la ligne que j'utilise pour le tunneling: 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.
Une 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,
- activer la verbosité de ssh (-v),
- vérifier les journaux ssh sur l'hôte local et les journaux sécurisés sur un distant,
- tester différents ports distants,
- vérifiez vos paramètres iptables (comme l'a dit Shadur).
Cela peut également être dû à 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 correspond à un service sur le port 5678 sur une machine distante.
Si le port 1234 sur la machine locale est déjà utilisé par un autre processus (peut-être une session ssh -f en arrière-plan), ssh ne pourra pas écouter sur ce port et le tunnel échouera.
Le problème est que ce message d'erreur peut signifier plusieurs choses, et "administrativement interdit" donne parfois la mauvaise idée. 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 déterminer quel processus est en cours d'exécution sur 1234. Vous devrez peut-être Sudo pour lsof pour répertorier les processus appartenant à d'autres utilisateurs. Ensuite, vous pouvez utiliser
ps aux | grep <pid>
pour savoir quel est ce processus.
Pour obtenir tout cela en une seule commande:
ps aux | grep "$(Sudo lsof -ti:1234)"
Dans mon cas, le problème était dû à la demande d'un tunnel sans accès Shell tandis que le serveur visait à forcer un changement de mot de passe sur mon compte. En raison de l'absence d'un shell, je ne pouvais pas voir cela et n'ai reçu que 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 s'est produite 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 un accès Shell et en modifiant le mot de passe. Ensuite, je pourrais simplement utiliser des tunnels sans accès Shell à nouveau.
Je suis extrêmement surpris que personne n'ait mentionné que cela pourrait être un problème DNS.
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)
Cela peut être présenté si remote n'est pas résoluble ou si vous avez entré une syntaxe inconnue comme je l'ai fait ici où j'ai ajouté un user@ à la logique de redirection de port (qui ne fonctionnera pas).
J'ai eu le même message en essayant de creuser un tunnel. Il y a eu un problème avec le serveur DNS du côté distant. Le problème a été résolu lors de son retour au travail.
J'ai eu ce problème lorsque j'essayais de me connecter via SSH avec un utilisateur qui n'était autorisé à se connecter qu'en utilisant 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 groupe sftponly équivalent, soit vous connecter en utilisant un utilisateur qui n'est pas limité à SFTP.
J'obtenais le même message lors du tunneling SSH vers 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.
Vérifiez si /etc/resolv.conf Est vide sur le serveur sur lequel vous êtes ssh-. Plusieurs fois, j'ai trouvé que cela était lié à un fichier /etc/resolv.conf Vide
S'il n'est pas root, vous pouvez simplement vérifier sur le serveur en essayant ping ou telnet (80) sur un nom d'hôte public, à savoir:
root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known
Après avoir ajouté des enregistrements de serveurs 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 (cela est généralement rempli avec des enregistrements de serveur de noms par le client DHCP sur le serveur, le cas échéant).
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/config eu:
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 dans case (capitalisation) entre SSHBeyondRemote.server.com:22 et sshbeyondremote.server.com:22.
Une fois que j'ai résolu le cas, je n'ai plus vu 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
J'ai vu cette erreur sur cygwin et cela devrait être vrai aussi pour Linux et a fonctionné pour moi. Dans mon cas, j'avais fait ssh -ND *: 1234 [email protected] et quand j'ai connecté un navigateur à ce serveur comp-socks, il a parcouru, mais sur le modèle où j'ai exécuté cette commande ssh, j'ai eu cette erreur apparaissant à la console avec chaque demande - pour un site au moins, bien que le navigateur l'ait récupéré via le proxy ou semblait le faire, du moins dans la mesure où j'ai vu l'âge principal. Mais faire ce changement s'est débarrassé du message qui a échoué
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 léger ajout à l'un des commentaires ci-dessus: "Un échec de résolution DNS peut provoquer cette erreur" - assurez-vous également que vous orthographiez correctement votre nom d'hôte.
Je viens de passer plus d'une heure à essayer de déboguer tous les paramètres ssh et il s'avère que je venais de mal orthographier amazonaws dans la commande, ce qui équivaut à la note d'échec de la résolution DNS ci-dessus.
Le firmware du routeur Asus RT68U (Merlin Asus) a un paramètre qui permet la redirection de port SSH, qui doit être activée:
La redirection de port dynamique a été configurée comme décrit dans: Dépannage du tunnel Dyamic
La raison pour laquelle j'ai eu ce message n'est pas la plus courante, mais elle mérite d'être mentionnée. 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'essayais d'ouvrir le transfert de tunnel vers 192.168.66.08, il échouait toujours, car '08' était interprété par gethostbyaddr comme un nombre octal invalide :)
Vérifiez votre routeur pour la protection DNS Rebinding . Mon routeur (pfsense) a la protection de reliure DNS activée par défaut. Il provoquait l'erreur "canal ouvert: échec administrativement interdit: ouverture échouée" avec SSH
Il semble qu'il y ait beaucoup de causes profondes possibles pour ce message. Dans mon cas, il était impossible d'accéder à la télécommande car je n'avais pas fourni correctement le fichier de clés .
Le -L option ajoute un saut SSH implicite (en utilisant efficacement l'hôte SSH explicite comme serveur bastion/jump). Il peut être plus facile de déboguer ceci en effectuant le saut explicitement et en créant un shell de connexion à la machine cible à l'aide de "proxycommand".
Une fois que cela fonctionne, vous pouvez effectuer le transfert de port en fonction du localhost de la machine cible (en supposant qu'il peut se connecter à lui-même):
-N -L 1234:localhost:1234
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)
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'IP du serveur configuré (et le nom DNS résolu avec les commandes Host/Dig) était 192.168.2.47. Une faute de frappe simple causée par une reconfiguration IP précédente. Après avoir corrigé/etc/hosts, la connexion au tunnel a fonctionné sans problème:
ssh [email protected] -L 3456:127.0.0.1:5901
Il est étrange que la véritable IP ait provoqué l'échec lorsque j'utilisais l'IP littérale localhost pour le tunnel. Distro: Ubuntu 16.04 LTS.
J'ai eu le même problème et j'ai réalisé que c'était DNS. Le trafic est tunnelisé mais la requête DNS n °. Essayez de modifier manuellement votre fichier d'hôtes DNS et ajoutez le service auquel vous souhaitez accéder.
Un autre scénario est que le service auquel vous essayez d'accéder n'est pas en cours d'exécution. J'ai rencontré ce problème l'autre jour pour me souvenir que l'instance httpd à laquelle je tentais de me connecter avait été arrêtée.
Vos étapes pour résoudre le problème seraient de commencer par la plus simple, qui va sur l'autre machine et de voir si vous pouvez vous connecter localement, puis vous remettre sur votre ordinateur client. Au moins, cela vous permettra de déterminer à quel point la communication ne se produit pas. Vous pouvez adopter d'autres approches, mais c'est celle qui a fonctionné pour moi.