[Windows] Se connecter en SSH derrière un serveur proxy

Si vous êtes en entreprise vous avez probablement un serveur proxy pour surfer sur Internet (parfois transparent), qui bloque un peu trop de choses. Mais sans ce proxy, internet ne fonctionne pas car les connections directes sont bloquées.

Voyons comment passer outre ce serveur proxy pour établir une connexion SSH pour surfer sans restriction via un proxy SOCKS 5 dans un tunnel SSH.

C'est une alternative qui permet d'atteindre un réseau distant (et internet) sans VPN.

Mise en garde : suivant la législation de votre pays vous vous exposez à des poursuites judiciaires si vous contournez un système de sécurité tel qu'un serveur proxy ou un pare-feu. Ceci étant dit, dans certains pays comme la Chine ce coutournement est nécessaire pour ne pas entraver la liberté d'expression à laquelle la censure porte atteinte.

Si vous êtes vous Linux rendez-vous sur la procédure Linux.

Quelques explications techniques

Pour des questions de sécurité (logs, filtrage) mais aussi de performance (cache, QoS), on utilise un serveur mandataire (proxy) dans la plupart des entreprises. Il permet de contrôler et d'enregistrer tous les flux sortants de façon centralisée pour être en conformité juridique (hadopi, loi n° 2006-64 du 23 janvier 2006).

Parce que les serveurs proxy sont parfois configurés de manière trop restrictive, voici comment passer à travers avec une connexion SSH pour surfer comme à la maison.

Les serveurs proxy ne peuvent pas vraiment "proxifier" les requêtes chiffrées en SSL,c'est le cas des sites sécurisés (HTTPS). Du coup ils se contentent de renvoyer directement ces flux via la méthode connect. Seule la première URL/IP de destination est loguée, mais tout le reste étant chiffré le proxy ne voit rien d'autre... En fait l'établissement de la connexion est quasi-directe.

Nous allons profiter du chiffrement HTTPS pour établir une connexion SSH. Pour y parvenir notre serveur SSH est en écoute sur le port 443, afin que le proxy laisse passer cette connexion en pensant qu'il s'agit d'un site en HTTPS (comme Gmail par exemple).

De mon côté j'utilise un routeur Netgear WNR3500L avec le firmware libre Tomato, sur lequel j'ai configuré une redirection entrante (NAT) du port 443 vers le port 22 de ce même routeur. Vous pouvez également modifier le port d'écoute du démon SSH en 443, mais je préfère laisser le port 22 en écoute sur mon réseau interne.

Mon routeur Netgear incorpore un serveur SSH. Si vous n'en avez pas une machine sous Linux dans votre réseau fera aussi l'affaire (ainsi qu'un NAS Synology si vous activez SSH). Pensez simplement à renvoyer le port 443 entrant vers l'IP (fixe ou dhcp statique) du serveur/NAS Linux. Pour Windows il faut utiliser CopSSH ou Cygwin.

Vous n'avez rien à installer pour le proxy SOCKS, cela se fait de façon transparente du côté du serveur SSH (port dynamique).

Sous Windows avec Bitvise SSH Client

Un tunnel peut tout à fait s'établir via PuTTY qui supporte la configuration d'un proxy (attention cela bug avec KiTTY pour une raison inconnue). Mais PuTTY n'est pas très agréable à utiliser et la configuration des tunnels l'est encore moins.

C'est alors que j'ai découvert Bitvise SSH Client, un client SSH gratuit pour les particuliers et particulièrement facile à utiliser :

Il permet de configurer un maximum de choses en un minimum de clic grâce à une interface intuitive et efficace :

1. client SSH avec proxy socks
2. Sauvegarde de profils
3. client SFTP
4. FTP to SFTP Bridge
5. client SSH (ligne de commande)
6. translation de port (bidirectionnel)
7. gestionnaire de clé SSH
8. ouverture de port dynamique pour le bureau à distance Windows (RDP)
9. et bien d'autres...

Le bureau à distance Windows (il mappe automatiquement un port aléatoire vers le 3389 de la machine distante) :

Client SSH intégré (ne demande de login) :

Ou encore le forward de port qui me permet d'atteindre mon routeur Tomato depuis le port 9999 sur ma machine locale :

Configuration

Il faut préciser le nom (ou ip) du proxy d'entreprise, celui qui est précisé dans votre navigateur (ouvrir le .pac si vous en avez un car l'adresse est dedans). Choisir proxy HTTP et ne PAS cocher "resolve DNS names locally" :

Dans l'onglet Services, complétez de la façon suivante :

Listen Interface: IP d'écoute du proxy socks (votre machine locale)
Liste Port: port d'écoute sur votre machine locale

Pour utiliser le tunnel il faudra préciser dans votre navigateur le proxy socks sur 127.0.0.1 avec le port 5000.

Voici la configuration pour surfer via le tunnel pour Firefox :

Et pour Internet Explorer et Google Chrome :

Attention : c'est la bande montante (upload) de votre connexion distante qui sera sollicitée lorsque vous surfez via le proxy socks. Si vous êtes en ADSL le débit sera donc de maximum 1 mbps (environ 100 ko/sec). Si vous êtes fibrés à 5, 10 ou 50 mbps ça ira donc nettement plus vite.

A contrario, si votre entreprise a un gros débit montant (upload) vous pourrez envoyer des fichiers chez vous à vitesse grand V puisque c'est votre bande descendante qui sera sollicitée (download).

Conclusion

Grâce à ce tutoriel vous savez maintenant comment sortir d'un réseau filtré ("proxifié" et "firewallisé") pour atteindre un second réseau plus ouvert (chez vous, chez un ami, en datacenter, etc).

Cependant vous devez gardez en tête que vous respectez la charte informatique que vous avez probablement signée... car, même si tout passe dans un tunnel, la première connexion sur le port 443 restera active ("established") et apparaîtra dans les journaux des firewalls/proxys. Il ne faudra pas longtemps à un admin réseau pour blacklister cette IP qui apparaît un peu trop souvent dans les logs, il peut même vous questionner à ce sujet. Plutôt que d'utiliser un nom de domaine, je vous invite à utiliser votre IP directe, nettement plus discret (sans parler du faire que les dyndns like peuvent être bloqués).

Gardez deux choses en tête :

• les résolutions DNS se feront sur votre réseau distant, ce qui permet de bypasser le filtrage DNS s'il y a dans l'entreprise
• vous pouvez établir des connexions sur toutes les IP de votre réseau sans avoir à forwarder un port à chaque fois car tout passera par le socks. Néanmoins tous les services ne passent pas correctement via socks, à vous de voir.

Dans le cas d'un hotspot (hôtel, restaurant, gare) n'autorisant que le surf web cela peut s'avérer très pratique pour se connecter à d'autres machines en SSH (rebond). Ou encore au travers d'une connexion mobile (3G) si votre FAI n'autorise que le surf, mais il faudra peut-être utiliser un user-agent mobile en cas de contrôle de paquets. Chez Free Mobile il n'y a aucun filtrage mais c'est souvent le cas chez les MVNO.

Enfin, si votre entreprise utilise un système d'inspection des paquets (le fameux DPI, c'est à dire que le firewall scrute la couche logicielle 7 du modèle OSI) alors il se peut que cette technique ne fonctionne pas. En effet le début de la trame ne contient pas de flux web mais l'établissement d'une connexion SSH, souvent bloquée.

A vous le surf non filtré !

Si vous utilisez Linux vous pouvez passer par le package connect-proxy qui fera l'objet d'un futur billet si vous êtes intéressés ?

Article original écrit par Mr Xhark publié sur Blogmotion le 26/11/2012 | 24 commentaires |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons