web-dev-qa-db-fra.com

Refus de connexion de proxy SOCKS sous tunnel ssh sous Firefox 47.0 / Kubuntu 16.04

J'ai des difficultés à établir des connexions avec des sites Web à l'aide de Firefox via un proxy SOCKS sous tunnel. SOCKS4/SOCKS5 ne fait aucune différence.

Je monte le tunnel avec

ssh -D 1234 [email protected]

ensuite, pointez le proxy SOCKS de Firefox sur localhost sur tcp/1234.

Un point clé à noter ici est que le tunnel que je configure est sur un serveur distant que j'utilise à cet effet depuis de nombreuses années. J'ai parcouru FF et d'autres navigateurs par proxy pour des milliers de sessions sur une douzaine de plates-formes différentes ou plus, sur tous les principaux systèmes d'exploitation. Une fois que je le fais fonctionner, cela fonctionne toujours bien. Cependant, sur ce cas particulier de FF, j'ai des problèmes bizarres et intermittents.

Le problème est que FF ne semble pas "vouloir" établir une connexion. Je tape une URL ou clique sur un lien et je instantanément j'obtiens "Impossible de se connecter"/"Firefox ne peut pas établir de connexion au serveur à ..." Lorsque je dis "instantanément", je signifie que cela me revient dans une petite fraction de seconde.

Alors je frappe "Try again" ou la petite flèche de rechargement. Et je le fais encore, et encore, et encore, aussi rapidement que possible. Et après quelques essais - parfois 3-4, parfois jusqu'à 15-20 - je reçois une connexion et tout fonctionne! Donc, la connexion tunnel/SOCKS est disponible, c'est simplement que FF refuse de l'utiliser jusqu'à ce qu'elle soit intimidée. Une fois la connexion établie, les recharges ultérieures ne la perdent pas.

J'ai quelques add-ons, mais a) je les ai désactivés de manière sélective sans aide, et b) j'ai (bien sûr) essayé le mode sans échec. Il n'y a pas de changement.

Aucune suggestion?

sshkubuntufirefoxtunnelsocks5
3
JD Baldwin

Malheureusement, ce problème est intermittent et cela a compliqué mes efforts de dépannage. La réponse donnée par @Terrance ci-dessus, que j’ai marquée comme étant la réponse, n’est en réalité pas une solution au problème. Cela semblait ​​fonctionner, et en fait ​​travailla pendant un moment. Ensuite, j'ai rencontré à nouveau des problèmes. Parfois, arrêter et redémarrer ma session SSH résoudrait le problème - pendant un certain temps - et parfois, le redémarrage ne ferait aucune différence.

La suggestion mentionnée ce fil ailleurs - c'est-à-dire, spécifier 127.0.0.1 plutôt que "localhost" dans les paramètres de proxy de navigateur - semblait également faire une différence mais était finalement inefficace. J'ai déjà répondu que c'était la différence essentielle entre les connexions de navigateur fonctionnant et ne fonctionnant pas, mais encore une fois, c'était prématuré. J'ai continué à rencontrer des problèmes intermittents dans la capacité de mon navigateur à établir des connexions avec des sites Web via le tunnel.

J'ai maintenant acquis suffisamment d'expérience supplémentaire avec ce problème et la solution mentionnée ci-dessous que je suis raisonnablement confiant dans ma conclusion qu'il existe un bogue de type délai d'expiration dans OpenSSH lui-même . BTW, ma version est

OpenSSH_7.2p2 Ubuntu-4ubuntu1, OpenSSL 1.0.2g-fips 1 mars 2016

Je base ceci sur a) le fait que le problème est clairement indépendant du navigateur (vérifié dans Firefox, Chromium et w3m) et b) le fait que l’utilisation d’un autre client ssh a résolu le problème de manière fiable.

J'ai téléchargé le code source et construit et installé PuTTY (à partir de ce lien ). REMARQUE: assurez-vous d'installer le paquet virtuel gtkgl-dev afin que la source PuTTY puisse trouver les fichiers d'en-tête. Ensuite, je l’ai configuré comme je l’ai déjà fait à maintes reprises dans Windows, et cela fait des merveilles depuis environ deux jours maintenant. ZERO échecs.

Je suis convaincu que c'est la solution et qu'il existe un bogue dans OpenSSH actuel. Je vais travailler à faire un rapport à cet effet.

Je sélectionne ma propre réponse en tant que Réponse pour cette question, bien que la réponse de @ Terrence ci-dessus reste une lecture très utile.

0
JD Baldwin

Je dois utiliser un proxy tous les jours au travail pour me connecter à des serveurs situés de l'autre côté d'un pare-feu. J'utilise aussi Firefox, Chrome et Ubuntu 16.04.

EDIT: J'ai oublié une partie de ceci. J'ai dû ajouter un délai d'expiration à un fichier de configuration ssh ou mon tunnel expirera et je perdrai ma connexion. Une fois les éléments suivants ajoutés, ma connexion reste ouverte:

Dans ~/.ssh/config ajoutez les informations suivantes ( si le fichier n'existe pas, créez-le. ). Cela enverra un serveur keepalive à votre tunnel toutes les 15 secondes.

Host *
ServerAliveInterval 15

J'ouvre ma connexion de tunnel avec la commande suivante:

ssh -CfND 1234 username@proxyhost

Puis dans Firefox sous le Paramètres de connexion dans le Configuration manuelle du proxy je ne remplis que le SOCKS Host: avec 127.0.0.1 et Port: 1234. Ensuite, je m'assure que SOCKS v5 est sélectionné. Notez également que je n’ai rien dans la boîte de dialogue Pas de proxy pour:

Je peux ainsi me connecter à mes hôtes sans aucun problème.

enter image description here

Ensuite, pour Chrome, j'exécute une ligne de commande afin de ne pas définir les paramètres sur Chrome à chaque fois que je souhaite passer par le proxy, puis aucun proxy. Pour connecter Chrome au proxy, exécutez la ligne suivante:

Nohup google-chrome-stable --proxy-server="socks5://127.0.0.1:1234" & > /dev/null 2>&1

from ssh manpage

 -C      Requests compression of all data (including stdin, stdout,
         stderr, and data for forwarded X11, TCP and UNIX-domain connec‐
         tions).  The compression algorithm is the same used by gzip(1),
         and the “level” can be controlled by the CompressionLevel option
         for protocol version 1.  Compression is desirable on modem lines
         and other slow connections, but will only slow down things on
         fast networks.  The default value can be set on a Host-by-Host
         basis in the configuration files; see the Compression option.

 -f      Requests ssh to go to background just before command execution.
         This is useful if ssh is going to ask for passwords or
         passphrases, but the user wants it in the background.  This
         implies -n.  The recommended way to start X11 programs at a
         remote site is with something like ssh -f Host xterm.

 -N      Do not execute a remote command.  This is useful for just for‐
         warding ports.

 -D [bind_address:]port
         Specifies a local “dynamic” application-level port forwarding.
         This works by allocating a socket to listen to port on the local
         side, optionally bound to the specified bind_address.  Whenever a
         connection is made to this port, the connection is forwarded over
         the secure channel, and the application protocol is then used to
         determine where to connect to from the remote machine.  Currently
         the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
         as a SOCKS server.  Only root can forward privileged ports.
         Dynamic port forwardings can also be specified in the configura‐
         tion file.

J'espère que cela t'aides!

5
Terrance