SSH et ses acolytes

SSH est un outil très puissant. Bien plus qu’un moyen de se connecter sur une machine, ce dernier permet de créer des tunnels, de copier/recevoir des fichiers et même d’exécuter des applications graphiques à distance ! Partons à la découverte de ses fonctionnalités et de quelques trucs et astuces comme les alias ou l’authentification par clé publique.

Alias SSH !

Tout d’abord, gagnons du temps ! Vous devez sans doute souvent taper de longues commandes SSH, du style

ssh -p 1337 user@long-hostname4-x43df.be

SSH propose un solution à ce problème. Il suffit de quelques lignes dans le fichier .ssh/config (créez le fichier et répertoire si besoin) :

1
2
3
4
Host monserveur
   Hostname long-hostname4-x43df.be
   user user
   port 1337

Vous connecter sur cette machine devient aisé : ssh monserveur

Connectez-vous par clé publique !

Se connecter par clé publique vous permet de ne plus devoir taper votre mot de passe. Comment ça fonctionne ? Au lieu de se baser sur votre mot de passe pour s’assurer de votre légitimité, ssh va se baser sur une paire de clés dite clé publique et clé privée. Pour faire simple, tout ce qui est chiffré avec une de ces deux clés est déchiffrable avec l’autre. On parle de chiffrage asymétrique. SSH utilise l’algorithme le plus connu : RSA.

Générons donc une paire de clés :

Générer une paire de clés
1
ssh-keygen -t rsa

ssh-keygen vous demande tout d’abord un endroit où stocker votre clé. La proposition par défaut est .ssh/id_rsa. Ça tombe bien, c’est aussi à cet endroit précis que SSH par défaut va chercher votre clé privée pour essayer de se connecter. Je vous conseille donc de simplement taper enter. Ensuite ssh-keygen va vous proposer de mettre une passphrase à votre clé, c’est à dire un mot de passe. Tapez entrée si vous ne souhaitez pas en mettre. L’inverse permet d’avoir une sécurité supplémentaire en cas de fuite de votre clé privée.

Maintenant, votre terminal ressemble à ceci :

ssh-keygen complet
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tycale/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tycale/.ssh/id_rsa.
Your public key has been saved in /home/tycale/.ssh/id_rsa.pub.
The key fingerprint is:
49:97:23:95:f0:3e:66:05:66:bd:24:b1:f5:06:68:56 tycale@vks18823
The key's randomart image is:
+--[ RSA 2048]----+
|        ..**E    |
|         =*=oo   |
|        oo*o..o  |
|       . = o..   |
|        S =      |
|         o .     |
|                 |
|                 |
|                 |
+-----------------+
$ ls ~/.ssh/
id_rsa  id_rsa.pub

Le fichier .ssh/id_rsa est votre clé privée à garder secrète. Le fichier .ssh/id_rsa.pub est votre clé publique, vous pouvez la distribuer autant que vous voulez !

Maintenant, il faut indiquer à votre serveur votre clé publique pour qu’il puisse vous reconnaître. Pour ce faire, vous devez récupérer votre clé publique (cat ~/.ssh/id_rsa.pub fera l’affaire), qui doit ressembler grossièrement à quelque chose du genre (en une ligne) : ssh-rsa AAAAB3NzaEAAAADAQ[..]K09L6mMoMLrUuH tycale@home. Pour aller l’indiquer dans le fichier .ssh/authorized_keys de votre machine distante (à nouveau, créez le fichier et dossier au besoin) (nano ~/.ssh/authorized_keys fera l’affaire). L’organisation du fichier authorized_keys est très simple, vous devez simplement faire en sorte que chaque clé publique se situe sur une ligne différente. Une fois effectué, votre prochaine connexion ssh à cette machine s’effectuera par clé publique !

Sachez que toute la procédure que vous venez d’accomplir pour indiquer votre clé publique à un hôte distant peut s’effectuer d’une simple commande grâce à l’utilitaire ssh-copy-id (pas installé par défaut sous mac os x) : ssh-copy-id user@host

Maintenant, il ne vous reste plus qu’à mettre votre clé publique sur le maximum de machines possible (dans le répertoire root de préférence). ;)

Jongler avec plusieurs paires de clés

Il peut être intéressant de générer plusieurs paires de clés. En générer deux par exemple, une contenant un passphrase pour la placer dans le root de vos machines distantes et l’autre sans passphrase pour une connexion rapide en tant que simple utilisateur. Pour ce faire, il suffit simplement de générer deux paires de clés avec ssh-keygen (et bien sûr de les nommer différemment!). Ensuite, c’est à nouveau ssh_config qui va nous sauver ! En effet, il est possible d’indiquer la clé à aller chercher en fonction de l’host comme ceci :

deux clés privées : id_rsa et root_id_rsa
1
2
3
4
5
6
7
8
9
host monserveur
   hostname long-hostname4-x43df.be
   user user
   port 22
host monserveur_root
   hostname long-hostname4-x43df.be
   user root
   port 22
   IdentityFile .ssh/root_id_rsa

Si vous n’indiquez pas la clé à aller chercher, ssh ira chercher la traditionnelle .ssh/id_rsa (à moins de passer l’argument -i à ssh).

Une fois que vous avez mis ce système en place, je vous conseille de désactiver l’authentification par mot de passe en tant que root sur votre serveur. C’est une ligne à changer (ou à rajouter) dans votre fichier /etc/ssh/sshd_config (côté serveur) :

Attention à la casse
1
PermitRootLogin without-password

Une fois la modification établie, il vous faut redémarrer votre serveur SSH ! Relisez bien vos modifications deux fois et gardez une console root sur votre machine au cas où le serveur SSH ne voudrait plus redémarrer. Une fois prêt, redémarrez ssh : /etc/init.d/ssh restart (ou service ssh restart ou encore /etc/rc.d/ssh restart en fonction de votre distribution linux).

SCP / SFTP

Récupérer ou envoyer des fichiers de manière sécurisée sur une machine s’avère très utile. Dans le cas précédent, au lieu de copier/coller notre clé publique, nous aurions pu tout simplement l’envoyer. Comment faire ? Rien de plus simple. La commande SCP est très souple. Voyons comment envoyer un fichier :

scp - envoyer un fichier - toutes les commandes suivantes font la même chose
1
2
3
4
5
6
7
# Copier le fichier local local_file.txt vers la machine distante 
# long-hostname4-x43df.be dans /home/tycale/file.txt
scp -P 1337 local_file.txt tycale@long-hostname4-x43df.be:/home/tycale/local_file.txt
# On peut utiliser nos alias !
scp local_file.txt monserveur:/home/tycale/
# Encore plus court !
scp local_file.txt monserveur:

Et comment récupérer un fichier :

scp - récupérer un fichier
1
2
3
scp monserveur:remote_file.txt remote_file.txt
# Ou plus court
scp monserveur:remote_file.txt .

Pour envoyer notre clé publique directement sur une machine, nous pouvons écrire: scp ~/.ssh/id_rsa.pub user@server:~/.ssh/authorized_keys (pour le peu que le dossier .ssh existe, attention cette méthode efface les autres clés publiques autorisées)

Un autre point intéressant possible avec scp est l’utilisation du joker * qui permet de remplacer n’importe quelle chaine de caractères comme dans votre terminal. Imaginez que vous devez rapatrier un fichier ayant pour nom “[teamBlaBla] Drive 1080p.vo.st.en.it.mkv” qui se situe dans le dossier “download” dans votre home (ceci est un exemple fictif, bien entendu). Pour ce faire, vous pouvez simplement écrire scp monserveur:/download/*Drive*.mkv ..

La commande sftp permet de faire la même chose que scp mais avec une interface console. Attention, les alias SSH ne fonctionnent pas par défaut avec cette commande. Pour avoir nos alias, il faut utiliser l’option -F comme ceci : sftp -F ~/.ssh/config. Je vous conseille de mettre l’alias suivant dans votre .bashrc (ou .zshrc) : alias sftp=‘sftp -F ~/.ssh/config’ Rien de très compliqué, quelques exemples se suffisent à eux-même :

SFTP - quelques exemples
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
sftp xxx@ssh.cluster003.ovh.net
Connected to ssh.cluster003.ovh.net.
sftp> pwd
Remote working directory: /homez.53/xxx
sftp> lpwd
Local working directory: /Users/tycale
sftp> ls
xxx.zip  backup_ovh     cgi-bin       www     kstc.tpl
sftp> get kstc.tpl
Fetching /homez.53/xxx/kstc.tpl to kstc.tpl
/homez.53/xxx/kstc.tpl                                100%   15KB  15.1KB/s   00:00
sftp> put kstc.tpl
Uploading kstc.tpl to /homez.53/xxx/kstc.tpl
kstc.tpl                                              100%   15KB  15.1KB/s   00:00
sftp> lcd dossier  
sftp> lpwd
Local working directory: /Users/tycale/dossier
sftp> cd www
sftp> pwd
Remote working directory: /homez.53/xxx/www

Remarquez que si vous voulez agir sur plusieurs fichiers à la fois, les commandes mput et mget dans SFTP vous seront plus qu’appréciables ! Tapez help dans sftp pour connaître toutes les commandes possibles et leurs actions. SFTP permet d’user de joker * comme scp. De plus, certaines versions permettent l’autocomplétion via la touche TAB comme dans votre terminal. Ainsi, si vous devez envoyer ou télécharger un fichier nommé “azertyuiopqsdfghjklm”, tapez simplement “azer” suivi d’un coup de tabulation sur votre clavier, le nom entier du fichier s’écrira.

Tunnel SSH

SSH permet de créer des tunnels. Mais qu’est-ce ? En gros, un tunnel SSH permet de créer un lien virtuel (chiffré, dans ce cas) entre deux ordinateurs. Ensuite le but est de faire passer du trafic par ce lien. Pour ce faire, on peut soit utiliser le protocole SOCKS pour faire transiter le trafic dynamiquement (voir plus loin). Ou spécifier des ports à écouter pour retransmettre de l’autre côté.

Il existe donc trois façons de créer un tunnel avec SSH. Laissez-moi vous présenter d’abord la plus magique, la dynamique.

Un tunnel dynamique

Pour illustrer ce qu’est un tunnel dynamique, nous allons se servir d’un serveur SSH pour le transformer en un proxy web.

Pour créer un tunnel qui nous permettra d’utiliser notre serveur SSH comme proxy, nous devons taper la commande:

Tunnel SSH dynamique sur le port local 9999
1
ssh -ND 9999 monserveur

L’argument N permet de dire que nous ne voulons pas de terminal distant. Quant à l’argument D, il permet de créer un tunnel de type dynamique SOCKS sur le port local 9999 de votre machine. Remarquez que nous utilisons ici à nouveau notre alias monserveur pour gagner du temps.

Maintenant, il suffit de se rendre dans les paramètres réseaux de votre navigateur web (exemple sous firefox) et d’y indiquer votre proxy SOCKS.

Remarquez que vous pouvez faire des exceptions pour certains domaines, plages d’IPs. Vous pouvez vous rendre sur le site web ifconfig.me pour vérifier que votre adresse IP ne correspond plus à celle de votre provider internet mais bien à celle de votre serveur.

Local port forwarding

Le but du “local port forwarding” est d’envoyer tous les paquets reçus sur un certain port local vers votre serveur sur un port défini. Pour mieux comprendre l’utilité de ce type de tunnel, prenons un cas concret.

La plupart des FAI (fournisseurs d’accès internet) ne laissent pas passer le trafic sur le port 25 à moins que vous ne passiez par leurs serveurs. Or, malheuresement pour vous, vous changez souvent de connexion internet… Cela veut donc dire que vous devez à chaque fois reconfigurer votre client mail en fonction de votre FAI pour pouvoir envoyer des mails… C’est ballot.

Imaginez que vous disposez d’un serveur mail sur votre serveur (SMTP, port 25). En instaurant un tunnel SSH en “local port forwarding”, vous pouvez indiquer à votre client mail que votre serveur SMTP est situé sur votre machine (localhost) et sur le port 2000. Ensuite pour faire passer vos mails par le serveur, il vous faut joindre l’adresse localhost:2000 à votre_serveur:25 via la commande suivante :

Un tunnel SSH en “local port forwarding”
1
ssh -N monserveur -L 2000:localhost:25

L’argument N permet de dire que nous ne voulons pas de terminal distant. Quant à l’argument L, il permet de préciser le port local à utiliser, l’adresse à binder et le port distant ciblé. Remarquez que nous utilisons ici à nouveau notre alias monserveur pour gagner du temps.

Remote port forwarding

Si avez compris le “local port forwarding”, vous n’aurez pas de soucis à comprendre le “remote port forwarding”. Il s’agit de la même chose mais dans l’autre sens. C’est à dire que vous demandez à votre serveur de vous renvoyer tout le trafic qu’il reçoit sur un certain port vers votre ordinateur.

Un cas drôle et concret d’une telle utilisation est de permettre depuis l’extérieur d’accéder à votre machine en forwardant un port vers votre port ssh local. En somme, si vous m’avez bien suivi, encapsuler du SSH dans du SSH…

Un tunnel SSH en “Remote port forwarding”
1
ssh -N monserveur -R 2000:localhost:22

Maintenant, n’importe qui peut tenter d’accéder à votre serveur SSH local avec la commande ssh user@long-hostname4-x43df.be -p 2000

Juste pour le plaisir et vous prouver que ça marche :

Connexion à partir de ma machine sur ma machine en passant par un tunnel ssh sur tycale.be
1
2
3
4
5
6
7
8
9
[tycale:~]% ssh tycale.be -p 2000
Password:
Last login: Sat Nov 10 08:03:48 2012 from 10.0.0.37
[tycale:~]% w
 8:04  up 6 days, 18:35, 13 users, load averages: 2,32 2,67 2,60
 USER     TTY      FROM              LOGIN@  IDLE WHAT
 tycale   console  -                Sam13   6days -
 [..]
 tycale   s015     -                 7:58       - ssh tycale.be -p 2000

C’est pas banal comme situation… Ici, c’est tout à fait inutile. Mais ça peut être très utile pour envoyer des fichiers depuis un ordinateur distant vers votre ordinateur tout en passant par internet et en chiffrant toute la correspondance. De plus, SSH étant rarement bloqué, vous ne devriez pas avoir de soucis pour contourner la plus part des firewalls.

Plus d’alias !

Sachez qu’il est possible de créer des alias avec ssh_config pour créer directement des tunnels ! Cela peut se réveler très utile si vous devez souvent créer un même tunnel SSH. Dans notre cas du serveur SMTP, il serait intelligent d’en faire un alias. Alors sans plus attendre, voici comment faire :

Des alias pour tout et partout !
1
2
3
4
5
Host smtp_tunnel
    HostName long-hostname4-x43df.be
    User user
    Port 1337
    LocalForward 2000 localhost:25

Et si vous voulez faire un alias pour un “remote port forwarding”, il s’agit du mot-clé RemoteForward tout simplement.

SSH et X11 forwarding

SSH ne s’arrête pas à la ligne de commande ! Grâce à SSH, vous pouvez executer des applications graphiques distantes !

C’est très simple de lancer une application distante sur votre machine :

1
ssh -X monserveur

Un shell normal apparait, lancez l’application graphique que vous voulez, tout bêtement. Attention, en fonction de la lourdeur graphique de cette dernière, cela peut prendre du temps… Voici un exemple depuis mon université :

Remarquez sur cette capture d’écran que ça ne pose auncun soucis de devoir passer le X11 forwarding à travers deux SSH. Comme tout à l’heure avec le “remorte port forwarding”, on encapsule juste du SSH dans du SSH à nouveau.

On peut arriver à des résultats assez drôles d’ailleurs, comme lancer sa session gnome de l’université sur son ordinateur !

Alias ? Bien sûr !

Vous vous en doutez, il y a aussi moyen de préciser dans votre fichier de configuration SSH qu’il faut activer le X11 forwarding. Pour ce faire, il faut utiliser le mot-clé ForwardX11 et mettre comme valeur “yes” (ou “no”). Activer le X11 forwarding entraine cependant un délai plus important lors de la connexion.

SSH, c’est bon. Mangez-en !

SSH permet de faire beaucoup de choses comme je viens de vous le montrer. Pour aller plus loin, n’hésitez pas à lire les man. Par exemple, pour voir toutes les options possibles dans votre fichier .ssh/config, rendez-vous dans le manuel ssh_config : man ssh_config.

À lire aussi

  • Proxychains : Tunneliser le trafic de vos applications à travers SSH

Comments