Un port redirigé par SSH n'est pas toujours un proxy SOCKS
Distinguez un transfert local SSH fixe d'un écouteur SOCKS dynamique avant de configurer une application.
Vous créez un tunnel SSH, vous saisissez 127.0.0.1 et son port dans les paramètres de proxy du navigateur, et rien ne se charge. L'écouteur fonctionne peut-être parfaitement. Il attend peut-être simplement le mauvais type de trafic.
| Transfert | Ce que l'application locale envoie | Choix de la destination |
|---|---|---|
-L | Le protocole ordinaire du service cible | Fixé dans la commande SSH |
-D | Une négociation SOCKS, puis le trafic de l'application | Demandé par le client SOCKS |
Pour un seul serveur web, il s'agit d'un transfert fixe :
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Visitez http://127.0.0.1:9080/ comme un site web. N'étiquetez pas le port 9080 comme SOCKS : il transfère des octets vers l'unique serveur web nommé dans la commande. Ouvrir un site sous un autre nom d'hôte peut aussi affecter son hébergement virtuel, ses redirections ou ses cookies.
Pour un écouteur SOCKS, la forme change :
ssh -N -D 127.0.0.1:1080 [email protected]Configurez l'application pour utiliser SOCKS à 127.0.0.1:1080. Saisir cette adresse directement dans la barre d'adresse du navigateur envoie une requête web à un écouteur SOCKS, une autre incompatibilité de protocole.
Le manuel d'OpenSSH documente les deux formes. Il existe une exception utile : transférer un proxy HTTP existant avec -L produit un port local qui parle le protocole de proxy HTTP, car sa destination fixe est elle-même un proxy HTTP. Le service à l'autre bout détermine ce qui relève d'un transfert fixe. Transférer un proxy existant via SSH conserve le protocole et le compte de ce proxy.