SSH: petit guide pratique

Written by Sebastien Lambot on . Posted in Réseaux, Unix / Linux

SSH est un protocole réseau sécurisé utilisé pour le transfert sécurisé de communications et l’exécution de commandes à distance. Ce petit guide illustre quelques cas d’utilisation qui peuvent s’avérer très pratiques pour la plupart des administrateurs systèmes.

ssh-logo1Lors des différents exemples, nous nous utiliserons la version SSH-2 du protocole, plus récente et plus sécurisée.

Se connecter à une machine distante

Si la machine distante fait tourner un serveur SSH (sshd), vous pouvez vous y connecter en utilisant la commande

ssh username@hostname

ou

ssh host -l username -p port

Transférer des fichiers

Le transfert peut se faire soit avec scp, soit avec sftp

SCP

Copier plusieurs fichiers (ou un directory complet avec l’option -r) vers un host distant:

scp file1 file2 username@hostname:./folder

Ou rapatrier les données en local:

scp username@hostname:file1 .

SFTP

La commande sftp va ouvrir une session capable d’utiliser les commandes standards de FTP, à savoir:

sftp username@hostname

put pour envoyer un fichier
get pour recevoir un fichier
ls liste les fichiers/dossiers distants
lls liste les fichiers/dossiers locaux
pwd affiche le dossier courant distant
lpwd affiche le dossier courant local
cd change de directory sur la machine distante
lcd change de directory sur la machine locale

Créer un tunnel SSH

Tunnel local

Permet de forwarder un port local vers le port d’un host distant. Par exemple, tout le trafic arrivant sur le port local 1234 est envoyé vers le port 25 du serveur destination.
L’option à utiliser est -L localport:destination:remoteport donc:

ssh user@host -L 1234:destination:25

Exemple pratique:

Je suis dans un environnement de travail, sur ma machine « work ». J’ai une machine chez moi, que j’appellerai « home », qui possède une adresse IP publique (grâce à dyndns par exemple), et qui fait tourner un serveur ssh. De mon environnement de travail, je souhaiterais atteindre le site website.org (sur le port 80 puisqu’il s’agit d’un trafic http) qui est malheureusement bloqué.

Je crée donc le tunnel en exécutant la commande:

ssh -L 1234:website.org:80 user@home

ssh_L

Le site est maintenant accessible en allant sur http://localhost:1234. Le trafic entre par le port local 1234 (ouvert uniquement pour l’interface loopback), est envoyé vers le serveur ssh « home », qui redirige la requête vers website.org sur le port 80. La résolution DNS de website.org se faisant par « home » et pas par « work ». On aurait donc très bien pu utiliser l’adresse localhost pour accéder au serveur « home ».

Le tunnel ne permet pas uniquement de faire transiter du trafic web, nous aurions pu tout-à-fait faire transiter du trafic ssh (ou tout autre type) vers un autre serveur:

ssh -L 1234:server2:22 user@home
ssh -p 1234 localhost

ssh_L2

La première commande crée un tunnel envoyant le trafic vers server2 (qui est sans doute inaccessible à partir de « work »). La seconde commande crée une session ssh sur ce serveur en se connectant sur le port local 1234. Nous avons donc créé une session ssh dans un tunnel ssh.

Si vous voulez ouvrir ce genre de tunnel à d’autres machines du réseau, vous pouvez spécifier l’interface réseau LAN au lieu du loopback. Il suffit pour celà de spécifier la « bind address » (ou ne pas en spécifier et précéder le port de « : » uniquement pour que le tunnel soit actif sur toutes les interfaces):

ssh -L 192.168.0.10:1234:website.org:80 user@home

Tunnel remote (ou reverse)

Le reverse tunneling permet de créer un tunnel vers une machine distante et d’ouvrir un port sur celle-ci afin que le trafic qui y entre soit redirigé vers une ressource accessible du côté client.

Exemple pratique:

Imaginons cette fois-ci que je sois chez moi, sur ma machine « home » et que je souhaite accéder à une page de l’intranet sur le réseau de mon travail qui est protégé par un firewall. La première solution serait d’utiliser un VPN. La seconde, vous vous en doutez, utilise SSH.

Comme pour le cas précédent, le tunnel doit être créé à partir de « work », donc derrière le firewall, dans le sens ouvert du traffic (outgoing) puisque celui-ci bloque le traffic entrant (incoming):

ssh -R 1234:intranet.local:80 user@home

ssh_R

La commande ci-dessus va créer un tunnel de « work » vers « home », va ouvrir le port 1234 en écoute sur la machine « home » et va forwarder tout le trafic arrivant sur home:1234 vers intranet.local:80. L’utilisateur qui se trouve donc devant la machine « home » pourra ainsi accéder à la page intranet en naviguant sur http://localhost:1234.

Le seul inconvénient est qu’il faudrait créer un tunnel pour chaque site à accéder. Mais encore une fois, ssh peut nous aider, cette fois en mode dynamique.

Tunnel dynamique

Le dynamic port forwarding nous permet de configurer un port local qui tunnellisera son trafic vers toutes les destinations accessibles par le serveur distant.

Exemple pratique:

Je suis sur ma machine « work » et souhaite accéder à diverses ressources accessibles par mon serveur « home » et bloquées par le firewall à mon travail. Je vais donc créer un tunnel dynamique sur un port local qui va renvoyer tout le trafic vers ma machine « home », qui s’occupera elle d’envoyer les requêtes sur mon réseau domestique.

ssh -D 1234 user@home

ssh_D

Il ne me reste plus qu’à configurer le proxy de mon browser internet pour le faire pointer vers localhost:1234.
Si vous avez tout suivi jusqu’ici, vous comprendrez que si je vais sur la page http://localhost, je tomberai sur l’interface web de mon serveur « home ».

Si vous utilisez l’outil PuTTY, il existe un sous-menu « tunnels » qui reprend les diverses configurations ci-dessus. Pour créer un tunnel dynamique, rien de plus simple:

ssh_1

N’oubliez pas de cliquer sur « Add » pour ajouter votre paramètre.

ssh_2

One more thing

Certains réseaux d’entreprise utilisent une authentification ntlm sous forme de login et mot de passe pour pouvoir aller sur internet. Celà peut se faire de manière visuelle (une fenêtre s’ouvre et vous rentrez vos identifiants) ou de manière automatique en utilisant par exemple votre compte Active Directory. Dans ce cas, vous risquez d’être confronté à une erreur d’authentification ntlm lorsque vous tenterez de créer votre session ssh.

Un petit utilitaire très pratique a été développé pour créer un proxy local ntlm par lequel vous devrez passer avant de créer votre session ssh: cntlm. Il fonctionne aussi bien sur windows que sur les systèmes Unix/Linux. Il suffit de l’installer, de modifier le cntlm.ini (les commentaires sont explicites) et de le démarrer. N’oubliez pas de configurer le proxy dans votre client ssh afin qu’il pointe vers le port local de cntlm, et qu’il résolve les DNS à la sortie du proxy (« Do DNS name lookup at proxy end: Yes »).

Si vous n’avez pas une version récente de votre navigateur internet, il se peut aussi que vous deviez configurer un paramètre afin qu’il fasse la résolution DNS à la sortie du tunnel SSH. Si vous utilisez firefox, allez sur « about:config » et modifiez la valeur de « network.proxy.socks_remote_dns » pour qu’elle soit à « True ». Ce paramètre est correctement configuré sur Chrome à partir de la version 4.0.

L’authentification SSH

Lorsque vous vous connectez à un serveur SSH, deux scénarios de connexion sont possibles. Soit un un mot de passe vous est demandé (le login étant « root » s’il n’est pas spécifié dans la commande), soit par un couple de clés. Et contrairement à d’autres protocoles, le cryptage de la connexion se fait avant l’authentification, ce qui signifie que vos mots de passe ne passent pas « en clair » sur le réseau!

Nous verrons les avantages et inconvénients de ces méthodes dans un prochain article.

Tags: ,

Trackback from your site.

Leave a comment

You must be logged in to post a comment.