Juste un post rapide pour parler de ce qu’on peut faire avec une connexion SSH.
- Le client :
- Pour ceux qui ont accès à un linux/unix la commande ssh est Le client parfait. Je rappelle que MacOS est un unix.
- Pour ceux qui ne possèdent qu’un windows putty est impeccable. Pour ceux qui ne possèdent pas les droit pour accéder à la base de registre (et oui putty y stocke sa conf), la version de putty par portable apps leur conviendra.
- Le serveur :
- Avoir un compte sur une machine à soi : Un linux ou un unix, c’est parfait. Le serveur s’appelle opensshd. Pour win, il existe un démon sshd sous cygwin. Pour les plus bourrins, une vmware avec un *nux n’est pas mal non plus.
- Avoir un compte sur une machine que l’on connait. Ca va du compte sur le serveur d’un ami, de sa dedibox, son serveur OVH ou un accès oublié dans son ancienne boite.
- Avoir un compte sur une machine inconnue. Il semblerait qu’il soit possible d’en avoir et la liste des serveurs qui en proposent sont là bas.
- Une fois une connexion obtenue, il reste à l’exploiter :
- Toujours marrant bien qu’inutilisable w3m qui même s’il reste un navigateur par la console est quand même mieux que l’ancêtre lynx.
- Plus pratique, le forward de port TCP. Ce sont des tunnels. Sous linux, cherchez du côté de l’option -L. Sous win, putty, dans l’arbre de la configuration Configuration > SSH, Tunnels. Par sécurité le tunnel ne forwarde que les connexions émanant du poste qui a initié la connexion. L’option -g lève cette restriction sous nux et une checkbox dans putty. Simple et pratique. Mais ça ne fonctionne que si la destination est statique et connue au moment de l’ouverture du tunnel et qu’il s’agit de TCP. De plus le tunnel a un sens (de la source vers la cible ou le contraire (option -R ou Remote dans putty)).
- Plus pratique encore le proxy socks ou port dynamique. C’est un proxy TCP. La connexion SSH prendra les flux en entrée et fera une résolution DNS une fois arrivé sur le serveur. Sous firefox, déclarez simplement un proxy SOCKS 5 avec le port qu’on a choisi comme ‘port dynamique’. Sous réserve d’avoir bien mis l’option qu’il fallait (sous firefox 2, il faut activer l’option network.proxy.socks_remote_dns dans about:config), on peut maintenant surfer via le tunnel et en chiffré. En fait du moment que l’application implémente la gestion des proxys Socks ça passera (Pidgin, ThunderBird,…). Mais encore une fois, la connexion a un sens (j’ai lu que SOCKS5 supportait le TCP et l’UDP mais je n’ai pas testé).
- Plus violent, le tunnel ethernet over SSH. Ca ne fonctionne pour l’instant que sous linux, l’option est -W. Il faut des droits particuliers et un peu de préparation l’interface tun sur le serveur et, ce qui n’est pas dit dans l’article, penser à mettre les routes ou le NATage qui vont bien pour que les paquets qui sortent du tunnel reviennent bien par le même chemin. On a ici affaire à un VPN LAN2LAN.
- Les problèmes restant sont peut être comment faire passer un SSH vers l’extérieur :
- Dans le cas d’un simple FW, il est peut être judicieux de faire écouter son serveur SSH sur les port 443 ou même 80.
- S’il y a un proxy sur la ligne ou bien si on héberge des sites web sur la machine, il faudra faire un peu de conf reverse proxy sur apache (ou squid mais bon je n’en ai pas sous le coude). En suite un httptunnel devrait passer.
- Si le proxy est plus costaud encore et bien, il y a sans doute un utilitaire à développer (un jour si j’ai le temps, la motivation, besoin de reconnaissance de ce monde hostile) ou alors la solution serait peut être de passer par autre chose comme l’ICMP ou (et c’est plus crédible) le DNS.
En petite note de fin, notez qu’il ne faut pas être irresponsable car vu les systèmes de traçage, on pourra presque toujours vous retrouver. Parfois, c’est même l’antivirus du poste qui cafte. Et pour le point final, je souligne que ce post est juste fait afin de recenser les possibilités. A vous d’approfondir.
