–

J’ai écrit ce document pour 2 raisons. La première est que j’en ai marre d’expliquer sans cesse à mes amis cette méthode, la deuxième est que c’est vraiment une méthode très pratique, puissante et qui n’a que quelques limitations (et encore – voir chapitre à venir : VPN sur SSH).

1. Avez-vous besoin de SSH au boulot ?

Vous êtes 8h par jour au boulot et le proxy chargé de la sécurité de l’entreprise se charge surtout de vous bloquer quelques sites web et quelques protocoles réseaux à priori non professionnels. En gros, il vous emmerde à longueur de temps et vous aimeriez pouvoir faire les choses suivantes depuis votre boulot :

• Lire vos mails en POP, IMAP (par un client mail classique plutôt que via le web et l’interface nullissime de votre fournisseur).
• Utiliser Jabber, ICQ, MSN (ou autre protocole) depuis le boulot pour pouvoir rester en contact avec belle-maman.
• Prendre le contrôle à distance (VNC, pcAnywhere etc) de votre PC perso avec sa ligne ADSL pour faire je ne sais quoi. D’autant plus que des outils comme VNC ne gèrent tout simplement PAS les proxys.
• Suivre les résultats du football ou consulter un site d’actualités – en général le proxy bloque largement les sites foot, jeux, facebook et bien d’autres.
• et plein d’autres choses encore…

Dans ce document, je présenterai le concept ainsi que la mise en oeuvre de la solution (sous Linux ou Windows).

2. Principe général

SSH est un outil qui permet de se connecter à une machine distante en mode texte. Sous Linux, on accède à un shell, sous Windows, on pourra voir ça comme l’accès à une fenêtre DOS, à priori pas très utile, certes. Ca ressemble donc de loin à une connexion telnet, sauf que c’est laaaaargement plus sécurisé (je n’en débattrai par ici mais vous pouvez me croire sur parole) et beaucoup plus puissant.
SSH permet notamment de faire du transfert de fichiers (SFTP) et surtout, des tunnels de communication, dans les deux sens (vous comprendrez plus tard). Un tunnel va servir à encapsuler (capturer) des flux réseaux entre le SSH client (votre PC en entreprise avec accès web restreints qu’on veut contourner) et votre serveur SSH (votre PC à la maison avec ADSL branché 24/24).

Tout se résume à ça : le client SSH établit une connexion avec le serveur SSH à travers le proxy en utilisant une connexion autorisée par le proxy (méthode CONNECT vers un port autorisé). Ensuite, grâce à ça, des tunnels vous permettront de faire passer presque n’importe quoi à travers le proxy (voir chapitre 4 sur les limitations de ce système).

Le client SSH que j’utilise est putty (premier lien sur google), c’est un client libre, gratuit etc, qui permet de faire du telnet, du ssh et surtout d’utiliser les fonctionnalités de ssh, les tunnels par exemple. Il sait aussi se connecter à travers un proxy.

3. Mise en place

3.1. Côté serveur SSH

Chez vous, il faut d’abord installer un serveur SSH.

3.1.1. Installation

Sous Linux, vous trouverez forcemment un paquet correspondant à votre distribution. Exemple sous Debian, tapez « apt-get install ssh » et ça devrait le faire.

Sous Windows, c’est moins simple. Je ne connais pas d’implémentation libre directement fonctionnelle sous Windows. Et comme vous n’allez quand même pas payer la version payante de www.ssh.com, vous devrez utiliser www.cygwin.com pour installer un « environnement Linux dans votre Windows ». Cet environnement comprend ensuite la plupart des outils Linux, dont OpenSSH bien sûr. Deux options (au moins) s’offrent à vous :

• Installer cygwin de manière classique avec ce qu’il faut, notamment le paquet ssh (il vous faudra lire un peu de doc à priori).
• Utiliser le projet sshwindows qui propose un programme d’installation global comprenant un cygwin minimaliste et sshd associé. Je n’ai pas testé personnellement cette solution.

Présentation barbare de l’installation de cygwin : dans les grandes lignes, vous téléchargez le setup.exe puis vous choisissez un miroir de téléchargement, vous installez le minimum vital (par défaut je crois) et vérifiez bien que le paquet ssh est inclus. Au final, vous obtenez une sorte de raccourci façon « fenêtre DOS », sauf que vous êtes dans un environnement Linux et disposez de sa panoplie d’outils en ligne de commande et même graphique si vous cherchez bien (pour peu que vous ayez installé les paquets qu’il faut).

3.1.2. Génération des clefs

Si vous ne connaissez pas le principe d’authentification par clefs de SSH, sachez juste que vous devez générer une paire de clefs cryptées utilisées pour la communication entre le serveur et les clients. Même si dans ce document je ne vais pas détailler l’authentification par clefs, mais juste par mot de passe, cette paire de clefs est nécessaire pour l’identification du serveur et pour les premières étapes de l’établissement de la connexion (par mot de passe).
Si vous avez installé SSH sous Debian, le programme d’installation génère automatiquiment les clefs, pour les solutions, je ne sais pas. Sous cygwin par exemple, vous devrez donc générer ces clefs via la commande « ssh-keygen -t dsa ». Vous pourrez voir ces clefs dans « /etc/ssh », les fichiers sont ssh_host_dsa_key*.

3.1.3. Etape supplémentaire pour Cygwin

Un détail sous cygwin (encoooooore), il faut que vous lisiez les docs pour savoir comment lancer le serveur SSH en tant que service Windows plutôt qu’à la main le matin en partant au boulot… (cherchez des infos sur le programme cygrunsrv.exe). Pour la version « packagée » par le projet sshwindows, je ne sais pas, lisez la doc.

Sous Linux, ce sera forcemment fait automatiquement.

3.1.4. Changement du port du serveur SSH

SSH tourne sur le port 22 par défaut et vous pouvez être quasimment sûr que le proxy du boulot bloque ce port. Donc vous ne pourrez pas atteindre votre serveur depuis chez vous. Ajoutez donc dans le fichier de configuration de sshd (/etc/ssh/sshd_config) une ligne « Port 443 » après la ligne « Port 22 » ou remplacez cette dernière. Redémarrez le service. On choisit le port 443 car c’est le port https par défaut et le proxy du boulot tolèrera forcemment ce port (au pire, prenez le port 80, http). De plus, https et SSH présentent des similitudes (la couche SSL) et donc utiliser le port 443 a l’avantage d’être plus discret (voir chapitre 4.2.).
Si votre firewall le tolère, vous pouvez aussi faire un forward du port 443 vers le 22 en ne laissant que la ligne « Port 22 » dans sshd_config.

3.1.5. Votre firewall

Enfin, vous avez certainement chez vous un firewall, n’oubliez pas d’ouvrir le port 443 ou 22 (voir chapitre précédent).
Vous avez très probablement aussi une adresse IP dynamique et donc il faut que vous vous trouviez un nom de domaine (essayez www.dyndns.org, ils ont un service gratuit et vous aurez un nom du style chezmoi.dyndns.org mis à jour à chaque reconnexion de votre ADSL). Sinon, vous devrez récupérer votre adresse IP tous les matins et priez pour que l’ADSL ne tombe pas auquel cas vous risqueriez de changer d’IP.

Je suppose maintenant que votre serveur est lancé, accessible depuis l’extérieur et qu’il fonctionne correctement.

3.2. Côté client SSH

3.2.1. Récupération des paramètres proxy

Pour les utilisateurs d’Internet Explorer, allez dans Outils -> Options Internet -> Connexions -> Paramètres réseaux. Vous aurez 2 possibilités, soit l’adresse et le port sont directement écrit :

Soit votre entreprise utilise un script d’autoconfiguration :

Dans ce dernier cas, téléchargez ce script en recopiant l’adresse dans votre navigateur. Ouvrez-le, c’est un fichier texte. C’est simple à comprendre et en général, les dernières lignes vous donnent le proxy qui permet d’atteindre les sites extérieurs (Internet). La fin ressemble à quelque chose comme « PROXY host:port ».

Si vous utilisez un autre navigateur (je l’espère pour vous , vous saurez sûrement où trouver ces informations.

3.2.2. Installation de putty (client SSH)

Téléchargez putty. Il n’y a pas d’installation, pas besoin d’être admin de son poste. Vous n’avez besoin que de putty.exe sinon prenez le zip qui contient tous les binaires. Le paramétrage se fait comme suit :

Vous saisissez dans le menu « Session » l’adresse du PC chez vous (IP ou DNS), précisez le protocole SSH et modifiez le port où tourne le serveur SSH (443 à priori – voir chapitres précédents).

Dans le menu « Connection », activez l’envoi de paquets vides réguliers, toutes les 10 secondes par exemple. La connexion SSH se faisant via la méthode CONNECT (comme pour du https), le proxy risque fort de la couper régulièrement si aucun trafic n’est généré.

Dans le menu « Proxy », vous indiquez le type de proxy, à priori HTTP, son adresse, son port et l’utilisateur/mot de passe si besoin. La ligne « telnet command » représente en gros le début de la communication entre putty et le proxy pour permettre la connexion au serveur distant (le PC chez vous). Tentez la ligne suivante : « connect %host %port HTTP/1.1\nHost: %host » si la ligne par défaut ne fonctionne pas.

Enfin, dans le menu « SSH », vous précisez que vous utilisez le protocole en version 2 et activez la compression – c’est toujours ça de gagné.

Retournez dans le menu « Session », donnez un nom à votre session et faites « Save » à nouveau. Puis « Open ».

3.2.3. Le moment de vérité

Faites « Open », si tout va bien, vous obtiendrez un écran du genre :

Connectez vous et ça roule. Dans les autres cas, vérifiez bien les informations saisies et éventuellement changez le type de proxy. Parmi les 25 entreprises que j’ai pu visiter (grandes multinationales comprises), seules 2 ont refusé cette connexion, la première car le proxy était un logiciel merdico-archaïque de Microsoft qui avait déjà du mal à fonctionner normalement avec IE, la deuxième car le proxy était buggé et avait l’air de ne pas respecter le protocole « normal » entre putty et le serveur ssh (d’après les traces que j’ai analysées, le serveur SSH était atteint puis tout partait n’importe comment).

A ce niveau là, si la connexion est établie et que vous pouvez accéder à votre machine, c’est banco, vous pourrez « tuyauter » n’importe quoi via SSH

3.3. Les tunnels

3.3.1. Créer un port mapping

Dans le menu « Tunnels », créez un tunnel vers vos serveurs de messagerie (ATTENTION, lisez le chapitre 4.1.3 à propos du forward de messagerie) :

Cette fois-ci, lorsque la fenêtre putty sera ouverte et que vous serez signé sur le serveur SSH, il y aura eu création d’un port mapping du port local 10110 du poste client vers le port 110 du serveur POP de votre provider (le tout via le relai SSH . Idem pour les ports 10025/smtp:25. J’ai choisi des numéros de ports locaux (10110 et 10025) différents des vrais ports notamment pour la compréhension. Rien (ou presque) ne vous empêcherait de mapper les port 25 et 110 vers les ports 25 et 110 des serveurs POP et SMTP de monprovider.com.

Ca veut dire que si un programme de messagerie (mozilla, thunderbird, outlook express, lotus notes etc) s’adresse à votre propre machine (localhost) sur le port 10025, c’est bien le serveur SMTP de monprovider.com:25 qui répondra. Idem pour le port 10110/110, c’est le serveur POP qui répondra. A partir de là, configurez votre client mail en indiquant que les serveurs POP et SMTP de monprovider.com sont respectivement localhost (sur port 10110) et localhost (sur port 10025).
Lorsque le client mail fera une requête, c’est putty qui interceptera la communication et dira au serveur d’effectuer la requête à partir de l’autre bout du tunnel vers le serveur:port précisé. Et voilà ! (j’espère que c’est clair

Attention : vérifiez bien que votre client mail n’utilise aucun proxy pour les connexions locales ! (exemple : « outlook express » utilise la configuration de IE, veillez bien à cocher dans IE la case qui précise de ne « pas utiliser de proxy pour les connexions locales », ça devrait être fait par défaut).

Avec un beau schéma, ça donne ça :

Maintenant que vous savez faire ça, vous pouvez mapper n’importe quoi et vous coimprendrez rapidement que le port mapping n’est pas la solution pour tous les problèmes. Exemple, si vous voulez faire de l’IRC, le serveur que vous joindrez ne sera pas toujours le même suivant les réseaux que vous voulez utiliser.

3.3.2. Tunnel dynamique (pour ICQ par exemple)

La limitation des port mapping apparaît rapidement car il faut définir absolument toutes les connexions dont vous avez besoin, ce qui peut être très lourd. Imaginez que vous vouliez mapper certains sites web interdits, comme www.pleindetrucsinterdits.com. Vous n’avez qu’à créer un port mapping du style « localhost:12345 -> www.pleindetrucsinterdits.com:80 ». Ca fonctionne – pas dans tous les cas à cause des « virtual hosts » (Merci Toine) – mais il ne faut pas avoir 50 sites à mapper sinon c’est l’enfer.

Une autre limitation est que vous ne pouvez tout simplement pas de cette manière vous connecter à certains services comme ICQ par exemple : en effet, vous pourriez faire un port mapping vers le serveur d’authentification login.icq.com:5190 par exemple, mais le reste de la communication ne se fera pas car il y a ensuite tout un tas de ports dynamiques alloués qui entrent en jeu. Impossible donc.

La solution est le mapping dynamique. En gros, vous créez un port d’écoute (port 1080 dans la suite du texte) qui se charge de prendre toute trame réseau qui rentre telle quelle et de la « faire exécuter » depuis l’autre bout du tunnel. Ca ressemble à un proxy n’est-ce pas ? En effet, c’est bien un service que l’on utilise pour contacter n’importe quel site/port inaccessible depuis le réseau où l’on est. C’est pas beau ça ?
Ca veut notamment dire que dans l’application qui doit utiliser ce « proxy », vous devez préciser que le nouveau proxy est localhost:1080 et non pas le proxy de l’entreprise.

Dans putty, créez un tunnel « Dynamic » sur le port 1080 par exemple :

Ca donne ça :

Et globalement, on peut donc schématiser ça comme ça :

ATTENTION : une fois ce système mis en place, n’oubliez pas de dire à l’application concernée que le proxy pour sortir n’est plus le proxy de l’entreprise mais le « proxy » de type SOCKS 4 (si vous avez besoin de le préciser) situé sur localhost, port 1080 ! Pigé ?

(MAJ 2009)
Si vous n’arrivez pas à faire utiliser ce proxy à votre navigateur, pourquoi ne pas installer un vrai proxy sur votre serveur relai et le mapper via un tunnel normal ? (un “squid” local à votre serveur relai fera l’affaire)

3.3.3. Tunnel remote ? Ou comment exporter un serveur local (interne) vers l’extérieur

Enfin, sur l’interface de putty, vous avez peut-être remarqué une fonctionnalité inexplorée jusqu’à présent : les tunnels « remote », par opposition aux tunnels « locaux ». Ca permet non pas de mapper un port local vers un couple machine/port distant mais de faire l’inverse : mapper un couple machine/port local vers un port distant (sur la machine PC ADSL). Vous ne voyez pas à quoi ça peut servir ? Lisez la suite :

Attention : c’est mal de faire ça car ça vous permet de rendre accessible un serveur d’Intranet (par exemple) à partir de votre machine extérieure (PC ADSL) et donc potentiellement accessible à tout le monde depuis le web si vous ne faites pas attention à votre configuration réseau !

4. Compléments d’informations

4.1. Limitations

4.1.1. Bande passante

Gardez à l’esprit que vous faites tout passer par la machine chez vous, certainement plus lente en débit que l’accès web de l’entreprise notamment pour l’upload (le retour de communication de votre PC ADSL vers putty). Donc si vous mappez des sites web interdits, ne vous étonnez pas si ça raaaaame, surtout si votre client favori de peer-to-peer tourne plein pot…

4.1.2. Jouer en réseau ?

Décidemment, votre boulot vous passionne… Bon désolé, c’est pas possible. La plupart des jeux en réseaux fonctionnent en mode non connecté (UDP) et c’est pas possible de relayer de l’UDP avec cette solution. Si vous voulez quand même, cherchez des infos sur un soft qui s’appelle ZeBeDee, j’avais pas eu le temps de creuser à l’époque.

(MAJ 2009) Sinon, pensez VPN, hamachi…

4.1.3. Remarques sur la messagerie

A propos du mapping vers des serveurs de messagerie, notez que les fournisseurs bloquent en général l’accès à leur propre SMTP si l’IP émettrice n’est pas sur une plage appartenant à l’opérateur. Pour éviter le spam d’inconnus. Donc évitez de passer par le SSH d’un copain ayant son accès web chez un autre fournisseur pour atteindre votre SMTP, ça risque de ne pas fonctionner. Exemple : vous voulez utiliser le SMTP de wanadoo en passant par une passerelle SSH chez Nerim.

Dans le même ordre d’idées, il faut en général faire du POP avant de pouvoir envoyer un mail, ça s’appelle pop before smtp me semble-t-il et c’est aussi fait pour s’assurer à peu près que l’adresse IP de l’émetteur du mail n’est pas un inconnu car il s’est authentifié par un login/password pour accéder au POP.

4.2. « Légalité » de la chose

Si vous avez peur qu’un gros baraqué de l’équipe réseaux débarque dans votre bureau en disant « qui c’est l’abruti qui fait du SSH ? », n’ayez pas peur.
Premièrement, la connexion au serveur SSH ne se traduit que par une ligne dans les logs du proxy, une ligne du style « CONNECT votrenom.dyndns.org:443 », exactement comme si vous vous connectiez au site https de votre banque. C’est même mieux vu qu’il n’y aura qu’une ligne alors que pour un vrai site web en http(s), il y a aura une ligne par ressource (image, page web etc).
Deuxièmement, au niveau volumétrie de données échangées, étudions l’exemple de la lecture de vos mails : on utilise grâce au tunnel SSH un protocole dédié à la lecture de mail et l’envoi (POP/SMTP). Ca consommera laaaaaaaargement moins de bande passante que de lire les même mails par l’interface web (bourrée de pubs par exempe). De plus, comme ça ramera moins que le chargement complet de pages web, vous mettrez moins de temps à lire vos mails.
Rassuré ?
Une nuance tout de même, si un psychopathe réalise qu’il s’agit de SSH sur port 443 et non de HTTPS, il devrait se poser des questions tout de même. Je n’ai pas encore rencontré de tels psychopathes.

Enfin, rappelez vous quand même la charte informatique que vous avez signée en rentrant dans votre entreprise.

4.3. Partage de tunnels ?

Si vous souhaitez faire profiter de votre tunnel un collègue qui tient absolument à suivre aussi le match de football bloqué par le proxy, regardez les options de putty/ssh pour permettr l’accès aux ports mappés depuis autre part que votre poste local. Exemple : votre collègue entrerait l’adresse ip de votre machine et un port mappé pour accéder à un site web particulier…

4.4. Bug dans putty

Je ne sais pas si ce bug est toujours d’actualité, mais à un moment donné, il fallait absolument mettre le tunnel dynamique en dernier dans la liste des tunnels, sinon il ne fonctionnait pas.

4.5. Transfert de fichier ?

Installez filezilla, il permet de faire du SFTP. Vous n’aurez pas besoin de tunnels SSH mais je tenais à signaler cet outil, libre, gratuit etc etc.
Il vous suffit de déclarer le proxy de l’entreprise dans les préférences puis de créer une connexion de type SFTP (changez le port en 443) et le tour est joué.

Sinon, sous Windows, le produit commercial « Total Commander » permet d’utiliser votre tunnel dynamique (SOCKS 4).

4.6. Méthodes alternatives

Si SSH ne vous plait pas (pauvre fou), vous pouvez toujours vous renseigner sur les outils suivants : httport, httptunnel (linux only je crois). Ils font un peu le même genre de choses, mais en laaaaaaaargement moins bien.
Les deux encapsulent votre trafic réseau dans des trames HTTP, c’est lourd, c’est lent etc. Le seul avantage de httport est que les éditeurs vous fournissent des serveurs (htthost) publics, donc pas besoin d’avoir un serveur relai chez vous ou chez un ami, mais ils rament, sauf si vous payez Quitte à mettre en place un outil pour faire relai, optez pour SSH !
(MAJ 2009)
A noter stunnel pour faire du tunnel SSL pur (si votre admin réseau a grillé votre communication SSH sur un port SSL…
(MAJ 2009)
Quelques liens récemment donnés par Toinator et que je n’ai pas creusé. Lui oui, c’est du lourd apparement.
Un bon gros guide :
http://dag.wieers.com/howto/ssh-http-tunneling/
sslh : en PERL (fixme : retrouver l’url)
sshl : le même recodé en C pour raisons d’optimisations

5. Remerciements

• Toinator pour la relecture et quelques précisions, l’initiation à ce genre d’outils et le chapitre à venir sur le VPN over SSH, si on peut dire.
• Mandraxe

Deux/trois tests plus tard, je vois le plan : ok pour les ports standards de bureautik-man à la plage (lire ses mails, naviguer sur Internet) mais le reste….. zob.
En gros, j’ai pu voir vite fait que ça passait pour les ports 80, 443, 465, 993 et 1194. Le reste j’ai pas cherché. A tous les coups, le 25, 143, 110 doivent passer aussi. Sans compter la miriade de saloperies de ports réseaux d’un Exchange / Active Dir. Ca doit marcher aussi, sinon comment faire pour vite vite reprendre sa propale depuis son transat ?

Alors bon, le VPN passe, donc c’est bon me direz-vous. Justement pas. S’il s’agit de dépanner le VPN ou si vous avez mis des restrictions sur le VPN (histoire que le VPN ne soit pas nécessairement une énorme porte ouverte dans l’entreprise), ça vous fait une belle jambe que le VPN fonctionne.

Conclusions :
1) Obligé de se taper des SSH sur port 443, des tunnels à gogo lorsque le VPN est trop restrictif…
2) Tu parles d’un accès web, tu peux même pas faire ce que tu veux. Pourtant, dès lors que le port 25 est ouvert, si la motivation principale est comme d’hab d’endiguer le spam des zombies etc, franchement, le mal est fait. Ca sert à rien de bloquer le reste.
3) Ou alors j’ai raté une conf quelque part pour ouvrir le port 22 ? je doute

C’est mes yeux ou c’est vraiment de l’accès restreint ce genre de connexion ?

Enfin, bientôt en vacances, c’est déjà ça…

Paquets requis:

• pour la partie FUSE (gérée par le kernel): fuse-utils et fuse-source (si vous utilisez un noyau custom) ;
• pour sshfs, sshfs.

La config de base, step by step:

1. ouvrir un terminal ;
2. se logguer en root (su -);
3. aptitude install fuse-utils sshfs (ça devrait aussi installer libfuse2 qui est une dépendance de fuse-utils);
4. éventuellement aptitude install fuse-source, puis module-assistant build fuse, … (mais bon, ça vous avez l’habitude non?);
5. faire en sorte que les utilisateurs de l’ordinateur qui utiliseront FUSE/sshfs fassent partie du groupe fuse (adduser leloginquivabien fuse);
6. éventuellement, chargez le module fuse (modprobe fuse).

Et voilà!

Utilisation à la mano, en ligne de commande:

C’est assez simple, dans votre terminal il vous suffit de taper une commande dont le synopsis est:

sshfs login@server:/chemin/du/dossier /point/de/montage [ -o idmap=user ]
• login est votre identifiant sur le serveur distant
• server est le nom du serveur distant ou son adresse IP
• /chemin/du/dossier… facile
• /point/de/montage l’endroit sur votre ordinateur où vous voulez trouver vos fichiers distants.
• -o idmap=user est utile uniquement si vos ID utilisateurs sont différents sur le serveur et votre machine, ça vous permet d’avoir un résultat lisible quand vous faire un ls -l dans /point/de/montage …

Donc, par exemple, je peux faire sshfs guillaume@guillaume.theflyingbear.net:/home/guillaume/public_html ~/mon_site pour accéder dans le répertoire mon_site à ma p’tite page ouaib.
Plus dangereux, je peux faire sshfs root@un_serveur:/etc /qqpart pour accéder au répertoire /etc d’un serveur mal configuré

Trucs et astuces (imaginez les bricol girls ou les garage babes vous l’annonçant, c’est plus sexy…)

sshfs vous demandera le mot de passe qui correspond à votre login sur le serveur distant à chaque fois que vous voudrez monter votre répertoire distant. Pour éviter cela, vous pouvez utiliser l’authentification par clef de SSH, en utilisant une clef sans phrase secrète (ssh-keygen(1) est votre ami)…

TODO

Utilisation de FUSE+sshfs avec mount et le le fichier /etc/fstab