sortie étrange sur tunneling ssh: échec de la sortie; échec de la connexion: la connexion a expiré;

18

J'utilise la ssh user@xx.yy.zz.41 -p 1234 -D 9898commande pour la tunnellisation, et je mets firefox socks5 ip à 127.0.0.1 et son port à 9898. Cela fonctionne avec succès, mais dans le terminal, j'ai une erreur de sortie:

channel 39: open failed: connect failed: Connection timed out
channel 41: open failed: connect failed: Connection timed out
channel 42: open failed: connect failed: Connection timed out
channel 43: open failed: connect failed: Connection timed out
channel 44: open failed: connect failed: Connection timed out

Cela se produit périodiquement. Qu'est-ce que c'est ça? C'est un problème? Que puis-je faire?

— Arash Mousavi
source

21

J'ai rencontré des problèmes similaires. Si vous tunnelez avec Firefox via ssh, certaines connexions http peuvent simplement expirer en raison de la charge du serveur ou d'une configuration incorrecte. Lorsque la connexion expire réellement, vous obtiendrez un message d'erreur comme celui que vous avez indiqué.

Vous pouvez supprimer ces messages avec la commande suivante

ssh user@xx.yy.zz.41 -p 1234 -D 9898 -q

Depuis la page de manuel ssh(1)

 -q      Quiet mode.  Causes most warning and diagnostic messages to be sup-
         pressed.

La suppression du message empêchera les avertissements de gâcher vos sessions ssh ou écran.

— Gordolio
source

Merci cette solution fonctionne très bien! Une question: ce délai d'expiration se produit périodiquement même lorsque tous les processus du navigateur sont fermés. J'essaie de déterminer ce qui cause le délai d'expiration et où la demande est envoyée. des suggestions sur la façon d'afficher des informations d'erreur plus détaillées pour le tunnel ssh?

— gnarbarian

3

Réglez le GatewayPortssur yeset réessayez.

ssh -o 'GatewayPorts yes' user@xx.yy.zz.41 -p 1234 -D 9898

man ssh_config

 DynamicForward
         Specifies that a TCP port on the local machine be forwarded over the secure channel, and the application protocol
         is then used to determine where to connect to from the remote machine.

         The argument must be [bind_address:]port.  IPv6 addresses can be specified by enclosing addresses in square
         brackets.  By default, the local port is bound in accordance with the GatewayPorts setting.  However, an explicit
         bind_address may be used to bind the connection to a specific address.  The bind_address of “localhost” indicates
         that the listening port be bound for local use only, while an empty address or ‘*’ indicates that the port should
         be available from all interfaces.

         Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh(1) will act as a SOCKS server.  Multiple for‐
         wardings may be specified, and additional forwardings can be given on the command line.  Only the superuser can
         forward privileged ports.

 GatewayPorts
         Specifies whether remote hosts are allowed to connect to local forwarded ports.  By default, ssh(1) binds local
         port forwardings to the loopback address.  This prevents other remote hosts from connecting to forwarded ports.
         GatewayPorts can be used to specify that ssh should bind local port forwardings to the wildcard address, thus
         allowing remote hosts to connect to forwarded ports.  The argument must be “yes” or “no”.  The default is “no”.

— quanta
source

1

J'utilise -o 'GatewayPorts yes' mais cette erreur s'est produite à nouveau.

— Arash Mousavi

GatewayPorts n'est pas le problème. Les ports de passerelle permettent au serveur ssh d'écouter les ports non locaux. GatewayPorts devient très utile lorsque vous effectuez un tunnel inverse - permettant aux hôtes du réseau privé de se reconnecter à votre hôte client ssh. Gordolio l'a juste au-dessus: le serveur SOCKS démarré par le ssh local se plaint quand il ne peut pas atteindre l'hôte / port demandé par les utilisateurs du client SOCKS (comme dans l'exemple de Gordolio, Firefox).

— Mark