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

185

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?

Neil
la source
Peut-être qu'il me manque quelque chose, mais pourquoi essayez-vous d'accéder à un serveur Web à l'aide d'un client ssh?
Faheem Mitha
Pourquoi envoyez-vous X11 (option -X) ici? Si vous souhaitez uniquement transmettre HTTP, cela n'est pas nécessaire. Et en guise de remarque, IMHO ssh est peut-être la mauvaise solution pour rendre un serveur Web disponible sur plusieurs ports.
Marcel G
29
J'ai trouvé que cela signifiait "Impossible de résoudre le nom d'hôte remote" dans mon cas.
RobM
3
Comme vous pouvez le voir sur la douzaine de réponses ci-dessous, le message d'erreur, malgré son aspect très spécifique, doit être compris comme une erreur générique. Généralement, la solution consiste à ouvrir un shell à distance et à essayer la même connexion pour en voir la cause réelle. Vous trouverez dans les réponses ci-dessous les causes réelles les plus courantes.
Stéphane Gourichon le
Un échec de la résolution DNS peut provoquer cette erreur ainsi que la connexion peut geler jusqu'à son expiration: superuser.com/a/700677
user423430

Réponses:

122

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.

hyperair
la source
Voici ce que j’ai spécifiquement ajouté à sshd_config pour que cela fonctionne: TCPKeepAlive oui AllowTCPForwarding oui PermitOpen any j’ai quelques "ouvert échoué" mais cela semble être une chose normale. Les choses fonctionnent très bien.
Pierre Thibault le
4
Remarque importante: vous pouvez obtenir cette erreur lorsque vous essayez de créer un périphérique tap / tun avec SSH et que SSH le permet, mais le noyau ne le permet pas. Cela peut se produire dans les conteneurs LXC. Voir blog.felixbrucker.com/2015/10/01/… pour les détails exacts, mais dans ce cas, vous voudrez peut-être ajouter lxc.cgroup.devices.allow = c 10:200 rwmà la configuration de votre conteneur et vous assurer que s'il /dev/net/tunn'existe pas, mknod /dev/net/tun c 10 200; chmod 666 /dev/net/tunest exécuté au démarrage dans le conteneur.
Azendale
@ Azendale, c'est intéressant, merci. Cela produit-il exactement le même message d'erreur ou quelque chose de légèrement différent?
hyperair
1
@ St.Antario, AllowTcpForwardingvous permet de transférer des ports TCP sur SSH, ce que -L 0.0.0.0:8984:remote:8983demande le paramètre. Si la valeur AllowTcpForwardingest définie sur no, SSH rejettera la demande de transfert de port, ce qui vous fera voir cette erreur.
hyperair
2
J'ai essayé de modifier les majuscules de AllowTCPForwardingà AllowTcpForwarding, mais SE veut au moins 6 caractères. Il suffit donc de noter que le cas correct est la Tcpversion, telle qu’elle a été utilisée correctement la première fois.
dbreaux
51

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.

Cobbzilla
la source
2
Merci, c'était le problème pour moi. J'ai créé le nom d'hôte pour l'adresse IP localement, mais pas sur le serveur ssh distant.
dev_feed
2
"le nom d'hôte cible de votre tunnel" est un peu difficile à déchiffrer. Pouvez-vous donner un exemple concret et réalisable qui me permettrait de prendre votre exemple et de remplacer le "nom d'hôte cible" dans votre exemple par mon nom d'hôte cible (une fois que j'ai compris ce que vous entendez par là) et avoir ce travail?
Terrence Brannon
1
Je ne suis même pas sûr que votre commentaire ait du sens. Vous dites que la machine distante n'avait aucune entrée pour localhost. Mais dites ensuite que l'hôte distant doit résoudre le nom d'hôte cible et non le nom d'hôte local. Encore une fois, un exemple concret complet de la situation avant et après serait utile.
Terrence Brannon
1
@TerrenceBrannon dans la commande ci-dessus, "localhost" est le nom d'hôte cible du tunnel . Lors de la création d'un tunnel SSH, la commande ssh se connecte d'abord au système distant ( 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-dessus localhost). 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ésoudre localhost, vous obtiendrez ce message d'erreur.
Cobbzilla
1
Dans mon cas, c’était aussi simple que d’avoir mal saisi le nom d’hôte cible, ce qui n’a bien sûr pas permis de résoudre le problème, mais mes yeux ont manqué de voir la faute de frappe trop longtemps.
Randall
25

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.

Neil
la source
2
Non ce n'est pas; J'utilise icmp-admin-allowed comme indicateur de rejet dans les configurations de pare-feu tout le temps.
Shadur
9
+1, le message interdit sur le plan administratif ferait croire à un blocage du pare-feu. Toutefois, vous recevez le même message lorsqu'il n'y a pas de blocage du pare-feu mais que l'ouverture échoue car il n'y a pas de route vers l'hôte distant.
Steve Buzonas
1
Je viens de passer plusieurs minutes à chercher ce problème dont le message n’a aucun sens dans mon contexte. Heureusement, il est assez clair lors de la vérification des fichiers journaux de la station intermédiaire.
Yaccz
En effet, si "distant" est inaccessible - car le nom d'hôte n'est pas résolu, hors connexion, n'existe pas, le nom d'hôte ne se résout pas - alors vous verrez ce message d'erreur.
Michael Martinez
18

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

jacquesjtheron
la source
Vous pouvez également voir la même erreur lorsque vous utilisez -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.
Timss le
10

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.

Matej Kovac
la source
Je suis venu ici pour savoir où définir cette limite de multiplexage ControlMaster. Si quelqu'un le sait, ils sont plus que bienvenus à partager.
Clacke
1
clacke: selon bugs.debian.org/cgi-bin/bugreport.cgi?bug=546854, vous pouvez ajouter un paramètre MaxSession dans le fichier / etc / ssh / sshd_config pour le définir. Selon la page de manuel, il est défini sur 10 par défaut.
oliver
@oliver: confirmation, MaxSession fonctionne, merci. heurté à 64 sur mon classeur.
Matej Kovac
2
Attention, ce n'est pas MaxSessionmais MaxSessions. Bien qu'il y ait quelques protections, ne cassez pas la configuration de votre serveur ssh ...
Stéphane Gourichon
8

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

Shadur
la source
5
Pas nécessairement. Le message est généré lorsque l'hôte ne peut pas répondre à la demande. Le cas est généralement dû au fait que l’administrateur a bloqué la connexion, mais il se peut également qu’il ne soit pas explicitement bloqué mais qu’il n’y ait pas de route vers l’hôte souhaité. AFAIK sshn’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.
Steve Buzonas
2
Euh non. Il existe une différence nette entre le type de réponse ICMP qui dit "pas de route à héberger" et celui qui dit "interdite administrativement", et à moins que quelqu'un ait délibérément mal configuré un routeur, ce dernier signifie exactement ce qui est écrit.
Shadur
1
On vient de me «interdire administrativement» lorsque j'utilise un nom d'hôte qui n'a pas été résolu, ce qui semble donc être un fourre-tout. Peut-être que ssh fait de la traduction?
Ganesh Sittampalam
5

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

lauhub
la source
localhost a probablement mappé sur :: 1 (ipv6) et vous n'y écoutiez pas pour une raison quelconque
Jo Rhett
4

Cela arrive aussi quand /etc/sshd_configa

AllowTcpForwarding no 

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

utilisateur578125
la source
4

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
tinlyx
la source
Merci beaucoup!
Thibaut Barrère
3

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).
Marco Solieri
la source
3

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.
Marciano
la source
3

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)"
Mnebuerquo
la source
2

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.

Leonardo Brunnet
la source
2

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 [email protected]: 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).

Torxed
la source
2

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.

Pieter Van Gorp
la source
1

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.

Mike
la source
1

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

Ender
la source
1

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.

SlavaSt
la source
0

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/

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
la source
Le tunnel AFAIK est activé par défaut, car sa désactivation n’ajoute aucune couche de sécurité, mais uniquement un inconvénient de l’ajout d’un tunnel tiers. Je rencontre un problème similaire lors de la tentative de proxy vers des serveurs internes depuis un emplacement hors site. La tunnelisation est activée + iptables est vidé avec une action par défaut ACCEPT.
Steve Buzonas
@SteveBuzonas Je le vois dans / etc / sshd_config donc a) cela ne désactive pas le tunneling b) en ce qui concerne ma réponse, la solution pourrait ne pas être une bonne idée. Voici ce que sshd_config dit à propos de cette option # Pour désactiver les mots de passe en texte clair tunnelés, choisissez no ici! #PermitTunnel no
barlop le
@SteveBuzonas vérifie que celui-ci est probablement non (non) et que vous pouvez utiliser un tunnel car l'effet de tunnel est activé par défaut.
barlop
Je pensais AllowTCPForwarding, Le commentaire que vous parlez # To disable tunneled clear textest en ce qui concerne d' PasswordAuthenticationêtre mis à pas, PermitTunnelest 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.
Steve Buzonas
0

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.

André M
la source
Un conseil général utile mais pas une réponse à la question posée.
Kyle Jones
0

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

meffect
la source
0

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.

Les données
la source
0

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)
diyisme
la source
0

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
Zach Pfeffer
la source
1
Si vous souhaitez créer un lien vers, promouvoir, citer ou faire référence à quelque chose que vous êtes affilié, vous devez divulguer explicitement cette affiliation. Il n'est pas suffisant de dire '' en mettant en place (lien) '' (car je ne comprenais pas ce que cela voulait dire jusqu'à ce que je sache que vous étiez en train de créer un lien vers votre propre blog); avoir une URL qui correspond à votre nom d'utilisateur Stack Exchange ne suffit pas. Références: Comment ne pas être un spammeur ,  évitez la promotion de soi-même ,… (suite)
Scott
(Suite)… et quand devrions-nous faire respecter l'exigence d'affiliation?    Vous êtes libre de mentionner votre blog, votre employeur, tout logiciel bien connu que vous avez développé, tous les livres que vous avez écrits, tout autre projet auquel vous êtes affilié, etc., dans votre page de profil utilisateur. .
Scott
0

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 [email protected] -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.

Fjor
la source
0

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

Philippe De Muyter
la source
0

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
nobar
la source