Seule difficulté, installer le module SSH pour PHP. Ce que je décris ici.
Ensuite, les bouts de codes exemple sont sur la doc de PHP.

Côté serveur Debian

J’étais parti de l’installation PECL directement, ça plante, il manquait des petits bouts côté Debian. Je montre pour l’exemple :

srv:~# pecl install ssh2 "channel://pecl.php.net/ssh2-0.11.2"
Failed to download pecl/ssh2 within preferred state "stable", latest release is version 0.11.2, stability "beta", use "channel://pecl.php.net/ssh2-0.11.2" to install
downloading ssh2-0.11.2.tgz ...
Starting to download ssh2-0.11.2.tgz (22,740 bytes)
........done: 22,740 bytes
[...]
checking for ssh2 files in default path... not found
configure: error: The required libssh2 library was not found.  You can obtain that package from http://sourceforge.net/projects/libssh2/
ERROR: `/tmp/pear/temp/ssh2/configure --with-ssh2' failed

Donc, il faut d’abord installer tout ça :

srv:~# apt-cache search libssh2
libnet-ssh2-perl - Perl module for the SSH 2 protocol
libssh2-1-dbg - SSH2 client-side library (debug package)
libssh2-1-dev - SSH2 client-side library (development headers)
libssh2-1 - SSH2 client-side library
libssh2-php - PHP Bindings for libssh2
python-libssh2 - Python binding for libssh2 library

srv:~# aptitude install libssh2-1-dev libssh2-php

Installation du module avec PECL

On peut donc enfin installer le module :

srv:~# pecl install ssh2 "channel://pecl.php.net/ssh2-0.11.2"
Failed to download pecl/ssh2 within preferred state "stable", latest release is version 0.11.2, stability "beta", use "channel://pecl.php.net/ssh2-0.11.2" to install
[...]
Build process completed successfully
Installing '/usr/lib/php5/20090626+lfs/ssh2.so'
install ok: channel://pecl.php.net/ssh2-0.11.2
configuration option "php_ini" is not set to php.ini location
You should add "extension=ssh2.so" to php.ini
aladdin:~# grep extension /etc/php5 -r
/etc/php5/conf.d/gd.ini:extension=gd.so
/etc/php5/conf.d/ssh2.ini:extension=ssh2.so
/etc/php5/conf.d/snmp.ini:extension=snmp.so

L’installation se charge toute seule d’activer l’extension ssh2.so dans les fichiers de conf PHP.

Exemple de code d’un transfert

define ("SSH_KEY","/path/to/.ssh/id_dsa");
define ("SSH_FINGERPRINT","BXXXXXXXXXXXXXXXXXXXXXX81"); # à récupérer la première fois
...
$ssh = ssh2_connect(SSH_SERVER,SSH_PORT);
if (ssh2_fingerprint ($ssh,SSH2_FINGERPRINT_MD5) != SSH_FINGERPRINT) { # bien penser à contrôler le fingerprint ; c'est dommage de s'en priver !
  echo "c'est mal";
}
if (!ssh2_auth_pubkey_file($ssh, SSH_LOGIN, SSH_KEY.".pub", SSH_KEY, '')) {
  echo "authentif par clef ratée";
}
...
if (@ssh2_scp_recv ($ssh, $fich_src, $fich_dest)) {
  echo "transfert OK";
}
...

Ce qui suit était valable jusqu’à ESXi 4.0. Je n’ai pas regardé en 4.1 pour l’instant. Vous me direz (ou moi plus tard).
Cet article explique comment activer le serveur SSH sur un hôte VMWare ESXi 4.0 et comment mettre en place un « authorized_keys » durable (car le home du root saute à chaque reboot). Je présente aussi rapidement quelques trucs indispensables pour se promener dans l’hôte.
L’intérêt de la chose est de pouvoir lancer directement certaines commandes depuis un serveur ESXi via une session SSH et aussi, pour l’authentification par clef, de scripter certaines choses. Par exemple l’arrêt / copie des fichiers vmdk / relance de serveurs pour automatiser des full backup offline.

Let’s go!

Activation du SSH

Ce n’est pas supporté par VMWare, mais ça existe quand même. On se demande bien pourquoi
Sur la console de votre hôte, vous appuyez sur ALT-F1 pour passer sur une session console « habituelle » du monde Linux.
Là, en aveugle (pas d’écho à l’écran), vous tapez « unsupported », sans les guillemets bien sûr et validez par la touche « Entrée ».
Vous obtiendrez une demande de mot de passe, le pass de votre compte root.
Ca y est, vous êtes connecté à la console.
Vous pouvez alors aller éditer le fichier /etc/inetd.conf, avec l’éditeur « vi » et décommenter la ligne SSH en IPv4.
Ensuite, soit vous redémarrez le serveur, soit vous redémarrez inetd.
Testez votre connexion SSH depuis un autre ordi, histoire de valider.

Et maintenant ?

Super, je peux faire du SSH sur le serveur, mais pour quoi faire ?
Personnellement, il m’arrive de déplacer des machines virtuelles d’un serveur à l’autre, dont les fichiers vmdk ne sont pas sur un SAN partagé. Plutôt que de super-galérer avec le « vSphere Client » -> « Browse datastore » -> etc, je préfère faire faire quelques « scp » par exemple.
Et surtout, vous pouvez faire tout ce que permet « vSphere Client » mais en mode texte. Bref, parfois, c’est pratique.

vim-cmd

L’outil essentiel est la command « vim-cmd » (rien à voir avec « VIm »), documentez-vous dessus.
Commencez par taper « vim-cmd » tout seul, puis « vim-cmd vmsvc/ » par exemple. Les noms de fonctions sont souvent éloquents.

Vous pourrez par exemple :

• obtenir la liste des VM : vim-cmd vmsvc/getallvms
• obtenir l’état d’une VM : vim-cmd vmsvc/power.getstate <ID>
• en arrêter proprement une (pas « électriquement ») : vim-cmd vmsvc/power.off <ID>
• en rallumer une : vim-cmd vmsvc/power.on <ID>

etc…

Stockage des machines virtuelles

Dans /vmfs/volumes/, vous trouverez les noms de code de vos « datastores » et des liens symboliques pointant vers ces noms pourris, histoire de s’y retrouver. Ces liens sont les noms que vous avez affecté via « vSphere Client ».
De là, vous allez vite retrouver vos fichiers vmdk & co.

authorized_keys

Si vous avez besoin de stocker dans le home du root (qui est « / » et non un habituel « /root ») un fichier « ~/.ssh/authorized_keys », sachez qu’il saute à chaque reboot.
Ce que j’ai fait pour contrer celà, c’est d’ajouter au script « /etc/rc.local » la recopie de ce fichier stocké au préalable dans un « datastore » local.
Ca donne :

~ # tail /etc/rc.local
         if [ -f $filename ] && [ -x $filename ]; then
            log "running $filename"
            $filename
         fi
      done
fi

mkdir /.ssh
cd /vmfs/volumes/DataStoreLocal/pour_reboot/.ssh/
cp authorized_keys /.ssh/

J’avais d’abord créé ce fameux « pour_reboot » + le répertoire « .ssh/ » + le fichier « authorized_keys » dans le datastore qui va bien (ce n’est pas son nom d’origine, c’est plutôt « datastore1″ sur une machine fraîchement installée).

Et voilà, avec un accès SSH, un hôte ESXi ressemble quand même plus à quelque chose, non ?

Il y a 3 méthodes courantes pour commencer à jouer avec les chroot ssh/sftp :

• Héberger un serveur SSH en chroot normal : c’est chiant. Créer un « home », reproduire un minimum d’arborescence standard, d’utilisateurs etc.
• Utiliser rssh comme shell alternatif, c’est un shell qui limite l’utilisateur à du SFTP, SCP, CVS, RSYNC etc. On choisit ce qu’on veut tolérer. Mais, l’utilisateur peut quand même se promener dans le système (tout « / »).
• Enfin, ce que je vais décrire : utiliser la fonctionnalité de « chroot » intégrée aux serveurs SSH (serveur ssh >= 4.8, donc n’importe quel SSH d’une Debian stable de nos jours). On va simplement brider quelques comptes et mettre quelques permissions bien senties.

Adaptation d’un utilisateur

Le mieux est de prévoir large : on risque d’avoir plusieurs clients/fournisseurs qui voudront accéder.
On va donc créer un groupe des utilisateurs SFTP seulement, nommé « sftpusers ».
Je crée un utilisateur pour mon client, nommé xfer1, en changeant son home :

xfer1:x:1011:1012:Transfert client1,,,:/transferts_partenaires/xfer1/:bin/bash

Notez que le groupe 1012 est le groupe « sftpusers » :

$ id xfer1
uid=1011(xfer1) gid=1012(sftpusers) groupes=1012(sftpusers)

Création du répertoire d’échange, permissions

On crée l’arborescence qui va servir de home bidon à tout ces utilisateurs :

$ mkdir --parents /transferts_partenaires/xfer1/
$ chown -R root:sftpusers /transferts_partenaires/
$ chmod -R 750 /transferts_partenaires/

Les permissions ci-dessus sont hyper importantes. Le serveur SFTP refusera la connexion si le home de ces utilisateurs n’est pas en écriture uniquement pour le root ! Donc oui, en l’état, notre utilisateur xfer1:sftpusers ne peut pas écrire dans son home. Il pourra lire, ce qui peut être suffisant si vous lui mettez simplement des fichiers à disposition. Mais pour écrire, il faudra créer un sous-répertoire, genre « upload ».

mkdir /transferts_partenaires/xfer1/upload/
chown xfer1:sftpusers /transferts_partenaires/xfer1/upload/
chmod 700 /transferts_partenaires/xfer1/upload/

Déclaration du compte en SFTP uniquement

Enfin, on paramètre le serveur SSH comme suit. Modifiez votre fichier /etc/ssh/sshd_config :

# param par défaut, on change : Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem     sftp   internal-sftp -f AUTH -l VERBOSE

# plus loin...
Match Group sftpusers
        ChrootDirectory /transferts_partenaires/%u
        ForceCommand internal-sftp
        AllowTcpForwarding no
        GatewayPorts no
        X11Forwarding no

A noter que les AllowUsers/DenyUsers s’appliquent toujours. L’utilisateur xfer1 – ou plutôt les utilisateurs du groupe sftpusers – doivent être autorisés d’une manière ou d’une autre.
A noter aussi la beauté du geste avec le « %u » pour indiquer le nom de l’utilisateur.

Ensuite vous recharger le serveur SSH et testez les connexions SFTP et SSH-qui-passent-pas, sans oublier la distinction lecture/écriture.

Let’s go
En relisant l’article, je vois que c’était vraiment vulgarisé pour être accessible au plus grand nombre, pardonnez donc les imprécisions techniques et le baratin simplifié – MERCI

–

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