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?
remote
" dans mon cas.Réponses:
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
,-L
ou-w
comme 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é suryes
PermitOpen
n'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
~/.ssh/authorized_keys
n'a pas de déclarationno-port-forwarding
oupermitopen
[2].PermitTunnel
Si 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.la source
lxc.cgroup.devices.allow = c 10:200 rwm
à la configuration de votre conteneur et vous assurer que s'il/dev/net/tun
n'existe pas,mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tun
est exécuté au démarrage dans le conteneur.AllowTcpForwarding
vous permet de transférer des ports TCP sur SSH, ce que-L 0.0.0.0:8984:remote:8983
demande le paramètre. Si la valeurAllowTcpForwarding
est définie surno
, SSH rejettera la demande de transfert de port, ce qui vous fera voir cette erreur.AllowTCPForwarding
àAllowTcpForwarding
, mais SE veut au moins 6 caractères. Il suffit donc de noter que le cas correct est laTcp
version, telle qu’elle a été utilisée correctement la première fois.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:
Le problème était que, sur l'hôte distant,
/etc/hosts
il 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
.la source
user@remote
), puis à partir de l'extrémité distante, elle configure des tunnels vers les hôtes cibles répertoriés (il s'agit de la commande ci-dessuslocalhost
). Ce faisant, il utilise le schéma de résolution du nom d'hôte sur l' hôte distant . Donc, si la machine sur laquelle vous êtes SSH ne peut pas résoudrelocalhost
, vous obtiendrez ce message d'erreur.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.
la source
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/config
fichier - et la machine distante ne savait rien de ce pseudonyme ...la source
-D
(DynamicForward) en tant que proxy SOCKS dans un navigateur. C'est-à-dire essayer d'accéder à un site Web que l'hôte du tunnel ne peut pas résoudre.Cette erreur apparaît définitivement lorsque vous utilisez les options ssh
ControlPath
etControlMaster
lors 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.la source
MaxSession
maisMaxSessions
. Bien qu'il y ait quelques protections, ne cassez pas la configuration de votre serveur ssh ..."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.
la source
ssh
n’a pas de logique pour déterminer la raison d’une connexion défaillante, il suppose simplement que si vous essayez de vous connecter, elle existe et que, si vous ne pouvez pas vous y rendre, la connexion doit avoir été bloquée intentionnellement.Un problème similaire
Une autre piste possible
J'ai eu le même problème en utilisant
~/.ssh/authorized_keys
avecpermitopen
.Pour
autossh
créer un tunnel, il me faut deux ports:Côté client
Cela m'a donné un problème similaire avec le port de surveillance:
J'ai eu ce message (après 10 minutes):
Côté distant
Mon
/var/log/auth.log
contenu:Dans mon
~/.ssh/authorized_keys
(côté distant) j'avais ceci:Comment le résoudre
J'ai résolu ce problème en remplaçant les
localhost
instances par127.0.0.1
:Il semble que SSH ne comprenne pas que
localhost
c’est un raccourci vers127.0.0.1
, d’où le message dansauth.log
et 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".
la source
Cela arrive aussi quand
/etc/sshd_config
aensemble. Basculez-le sur
yes
pour autoriser le transfert TCP.la source
Dans mon cas, j'ai dû remplacer
localhost
par127.0.0.1
:pour le faire fonctionner.
J'essayais de
rdesktop -L localhost:1234
suivre 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'illocalhost
est des/etc/hosts
deux côtés.Rien n'a fonctionné jusqu'à ce que je modifie la
ssh
commande elle-même en:la source
Une certaine activité de dépannage est nécessaire pour trouver une réponse définitive:
la source
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
la source
Cela peut également être causé par l'impossibilité de se connecter au port du côté local.
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
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
pour savoir ce que ce processus est.
Pour obtenir tout cela en une seule commande:
la source
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.
la source
Je suis extrêmement surpris que personne n'ait mentionné qu'il pourrait s'agir d'un problème de DNS.
Cela peut être présenté si la
remote
ré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émentuser@
à la logique de transfert de port (qui ne fonctionnera pas).la source
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
Ma configuration de tunnel était la suivante:
L'erreur affichée lors de la connexion directe au serveur (sans -N -f):
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.
la source
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
:Donc, dans ce cas, pour utiliser SSH, vous devrez soit supprimer l'utilisateur du
sftponly
groupe équivalent , soit vous connecter en utilisant un utilisateur qui n'est pas limité à SFTP.la source
Vérifiez si
/etc/resolv.conf
est vide sur le serveurssh
auquel vous vous connectez. Plusieurs fois, j'ai trouvé qu'il s'agissait d'un/etc/resolv.conf
fichier vide .S'il n'est pas root, vous pouvez simplement vérifier sur le serveur en essayant un
ping
outelnet
80 () sur un nom d'hôte public, c'est-à-dire:Après avoir ajouté les enregistrements du serveur de noms à
/etc/resolv.conf
: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).la source
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.
la source
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 [email protected] 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/
la source
ACCEPT
.AllowTCPForwarding
, Le commentaire que vous parlez# To disable tunneled clear text
est en ce qui concerne d'PasswordAuthentication
être mis à pas,PermitTunnel
est un paramètre pour permettre couche 2 ou 3 tunnels de réseau via tun / tap et par défaut non. Les options L, R et D utilisent le transfert TCP et non un périphérique pour la tunnelisation.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.
la source
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
la source
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.
la source
Mon cas:
la source
J'ai eu cette erreur en écrivant cette entrée dans mon blog :
/etc/ssh/sshd_config
avait quelque chose comme:Mais
~/.ssh/config
avait: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:
Version du serveur OpenSSH:
la source
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:
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é:
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 source
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 :)
la source
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):la source