Chapitre 40. L'accès à distance par SSH

Chapitre 40. L'accès à distance par SSH
Précédent	Partie IV. Debian GNU/Linux en réseau	Suivant

1. Introduction et mise-en-garde

1.1. Qu'est-ce que SSH ?

SSH signifie Secure SHell. C'est un protocole qui permet de faire des connexions sécurisées (i.e. chiffrées) entre un serveur et un client SSH. Nous allons utiliser le programme OpenSSH, qui est la version libre du client et du serveur SSH.

1.2. Mise en garde sur la sécurité

Nature du problème

Installer un serveur SSH permet aux utilisateurs d'accéder au système à distance, en rentrant leur login et leur mot de passe (ou avec un mécanisme de clefs). Cela signifie aussi qu'un pirate peut essayer d'avoir un compte sur le système (pour accéder à des fichiers sur le système ou pour utiliser le système comme une passerelle pour attaquer d'autres systèmes) en essayant plein de mots de passes différents pour un même login (il peut le faire de manière automatique en s'aidant d'un dictionnaire électronique). On appelle ça une attaque en force brute.

Il y a donc trois contraintes majeures pour garder un système sécurisé après avoir installé un serveur SSH :

avoir un serveur SSH à jour au niveau de la sécurité, ce qui doit être le cas si vous faites consciencieusement les mises à jour de sécurité en suivant la procédure Debian, comme expliqué au Chapitre 21 ;
que les mots de passes de TOUS les utilisateurs soient suffisamment complexes pour résister à une attaque en force brute ;
surveiller les connexions en lisant régulièrement le fichier de log /var/log/auth.log.

Choisir des mots de passe complexes

Un mot de passe complexe est un mot de passe qui ne veut rien dire, qui n'est pas dans le dictionnaire et qui comporte au moins 8 caractères, de préférence avec un mélange de lettres minuscules, de lettres majuscules, de chiffres et de caractères de ponctuation.

Une bonne méthode pour obtenir un mot de passe complexe et facile à retenir consiste à choisir une phrase et à prendre la première lettre de chaque mot, avec quelques complications en plus.

Par exemple, la phrase « Linux, moi j'y comprends rien de rien ! » donne le mot de passe L,mj'ycr2r!

Tester la complexité des mots de passe

Pour vérifier que les mots de passe des utilisateurs du système sont vraiment complexes, le root peut les soumettre à un cracker de mots de passe… et voir combien de temps ils résistent !

Les mots de passes des utilisateurs sont stockés dans le fichier /etc/shadow. Seul l'utilisateur root peut lire ce fichier. Pour tester la complexité des mots de passes, root peut donc installer le programme john et le lancer sur le fichier /etc/shadow :

# aptitude install john
# john /etc/shadow

Quand john a trouvé un mot de passe, il l'affiche avec le login associé.

Attention, john utilisera le processeur à 100 % ! Il est donc conseillé de lui donner une priorité faible (commande nice ou renice) si la machine doit être utilisée pendant ce temps. Plus le nombre d'utilisateurs est grand, plus il faudra laisser tourner john longtemps pour que le test soit significatif.

2. Le système de clefs de SSH

La théorie de la cryptographie asymétrique

SSH utilise la cryptographie asymétrique RSA ou DSA. En cryptographie asymétrique, chaque personne dispose d'un couple de clef : une clé publique et une clef privée. La clé publique peut être librement publiée tandis que la clef privée doit rester secrète. La connaissance de la clef publique ne permet pas d'en déduire la clé privée.

Si Alice veut envoyer un message confidentiel à Bob, elle doit le chiffrer avec la clef publique de Bob et lui envoyer sur un canal qui n'est pas forcément sécurisé. Seul Bob pourra déchiffrer ce message en utilisant sa clef privée.

La théorie de la cryptographie symétrique

SSH utilise également la cryptographie symétrique. Son principe est simple : si Alice veut envoyer un message confidentiel à Bob, Alice et Bob doivent d'abord posséder une même clef secrète. Alice chiffre le message avec la clé secrète puis l'envoie à Bob sur un canal qui n'est pas forcément sécurisé. Bob déchiffre alors le message grâce à la clef secrète. Toute autre personne en possession de la clef secrète peut également déchiffrer le message.

Les algorithmes de chiffrement symétrique sont beaucoup moins gourmands en ressources processeur que ceux de chiffrement asymétrique… mais le gros problème est l'échange de la clef secrète entre Alice et Bob. Dans le protocole SSL, qui est utilisé par SSH et par les navigateurs Web, la cryptographie asymétrique est utilisée au début de la communication pour que Alice et Bob puissent s'échanger une clef secrète de manière sécurisée, puis la suite la communication est sécurisée grâce à la cryptographie symétrique en utilisant la clef secrète ainsi échangée.

L'établissement d'une connexion SSH

Un serveur SSH dispose d'un couple de clefs RSA stocké dans le répertoire /etc/ssh/ et généré lors de l'installation du serveur. Le fichier ssh_host_rsa_key contient la clef privée et a les permissions 600. Le fichier ssh_host_rsa_key.pub contient la clef publique et a les permissions 644.

Nous allons suivre par étapes l'établissement d'une connexion SSH :

Le serveur envoie sa clef publique au client. Celui-ci vérifie qu'il s'agit bien de la clef du serveur, s'il l'a déjà reçue lors d'une connexion précédente.
Le client génère une clef secrète et l'envoie au serveur, en chiffrant l'échange avec la clef publique du serveur (chiffrement asymétrique). Le serveur déchiffre cette clef secrète en utilisant sa clé privée, ce qui prouve qu'il est bien le vrai serveur.
Pour le prouver au client, il chiffre un message standard avec la clef secrète et l'envoie au client. Si le client retrouve le message standard en utilisant la clef secrète, il a la preuve que le serveur est bien le vrai serveur.
Une fois la clef secrète échangée, le client et le serveur peuvent alors établir un canal sécurisé grâce à la clef secrète commune (chiffrement symétrique).
Une fois que le canal sécurisé est en place, le client va pouvoir envoyer au serveur le login et le mot de passe de l'utilisateur pour vérification. La canal sécurisé reste en place jusqu'à ce que l'utilisateur se déconnecte.

La seule contrainte est de s'assurer que la clef publique présentée par le serveur est bien sa clef publique… sinon le client risque de se connecter à un faux serveur qui aurait pris l'adresse IP du vrai serveur (ou toute autre magouille). Une bonne méthode est par exemple de demander à l'administrateur du serveur quelle est le fingerprint de la clef publique du serveur avant de s'y connecter pour la première fois. Le fingerprint d'une clef publique est une chaîne de 32 caractères hexadécimaux à peu près unique pour chaque clef (un hachage) ; il s'obtient grâce à la commande ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub.

3. Installation et configuration de SSH

Installation du serveur SSH

Le client SSH est disponible dans le paquet openssh-client, qui est préinstallé.

Pour pouvoir vous connecter à distance, vous pouvez maintenant installer le serveur SSH :

# aptitude install openssh-server

L'installation comporte une étape de génération des clefs de chiffrement. Finalement, le serveur SSH se lance.

Configuration du serveur SSH

Le fichier de configuration du serveur SSH est /etc/ssh/sshd_config. À ne pas confondre avec le fichier /etc/ssh/ssh_config, qui est le fichier de configuration du client SSH.

Nous allons vous commenter les lignes les plus importantes de ce fichier de configuration :

```
Port 22
```
Signifie que le serveur SSH écoute sur le port 22, qui est le port par défaut de SSH. Vous pouvez le faire écouter sur un autre port en changeant cette ligne. Vous pouvez aussi le faire écouter sur plusieurs ports à la fois en rajoutant des lignes similaires.
```
PermitRootLogin yes
```
Signifie que vous pouvez vous connecter en root par SSH. Vous pouvez changer et mettre no, ce qui signifie que pour vous connecter en root à distance, vous devrez d'abord vous connecter par SSH en tant que simple utilisateur, puis utiliser la commande su pour devenir root. Sans cela, un pirate n'aurait qu'à trouver le mot de passe du compte root, alors que là, il doit trouver votre login et votre mot de passe.
```
X11Forwarding yes
```
Signifie que vous allez pouvoir travailler en déport d'affichage par SSH. Ce sera expliqué plus tard, dans le Chapitre 42.

Si vous avez modifié le fichier de configuration du serveur, il faut lui dire de relire son fichier de configuration :

# /etc/init.d/ssh reload
Reloading OpenBSD Secure Shell server's configuration.

4. Se connecter par SSH

4.1. Authentification par mot de passe

C'est la méthode la plus simple. Depuis la machine cliente, tapez :

% ssh login@nom_DNS_du_serveur_SSH

Astuce

	Astuce
Si vous utilisez le même identifiant sur le client et sur le serveur, vous pouvez vous contenter de taper : `%` `ssh nom_DNS_du_serveur_SSH`

Si vous utilisez le même identifiant sur le client et sur le serveur, vous pouvez vous contenter de taper :

% ssh nom_DNS_du_serveur_SSH

Si c'est la première connexion SSH depuis ce client vers ce serveur, il vous demande si le fingerprint de la clef publique présentée par le serveur est bien le bon. Pour être sûr que vous vous connectez au bon serveur, vous devez connaître de façon certaine le fingerprint de sa clef publique et la comparer à celle qu'il vous affiche. Si les deux fingerprints sont identiques, répondez yes, et la clef publique du serveur est alors rajoutée au fichier ~/.ssh/known_hosts.
Si vous vous êtes déjà connecté depuis ce client vers le serveur, sa clef publique est déjà dans le fichier ~/.ssh/known_hosts et il ne vous demande donc rien.

Ensuite, entrez votre mot de passe... et vous verrez apparaître le prompt, comme si vous vous êtiez connecté en local sur la machine.

4.2. Authentification par clef

Au lieu de s'authentifier par mot de passe, les utilisateurs peuvent s'authentifier grâce à la cryptographie asymétrique et son couple de clefs privée/publique, comme le fait le serveur SSH auprès du client SSH.

Générer ses clefs

Pour générer un couple de clefs DSA, tapez :

% ssh-keygen -t dsa

Les clefs générées ont par défaut une longueur de 1024 bits, ce qui est aujourd'hui considéré comme suffisant pour une bonne protection.

La clef privée est stockée dans le fichier ~/.ssh/id_dsa avec les permissions 600 et la clef publique est stockée dans le fichier ~/.ssh/id_dsa.pub avec les permissions 644.

Lors de la création, OpenSSH vous demande une pass phrase qui est un mot de passe pour protéger la clef privée. Cette pass phrase sert à chiffrer la clef privée. La pass phrase vous sera alors demandée à chaque utilisation de la clef privée, c'est-à-dire à chaque fois que vous vous connecterez en utilisant cette méthode d'authentification. Un mécanisme appelé ssh-agent permet de ne pas rentrer le mot de passe à chaque fois, comme nous le verrons un peu plus loin dans ce chapitre.

	Note
	Vous pouvez à tout moment changer la pass phrase qui protège votre clef privée avec la commande ssh-keygen -p.

Autoriser votre clef publique

Pour cela, il suffit de copier votre clef publique dans le fichier ~/.ssh/authorized_keys de la machine sur laquelle vous voulez vous connecter à distance. La commande suivante permet de réaliser cette opération via SSH :

% ssh-copy-id -i ~/.ssh/id_dsa.pub login@nom_DNS_du_serveur

Se connecter

La commande est la même que pour une authentification par mot de passe.

5. Transfert de fichiers par SSH

5.1. En console

Le transfert de fichiers par SSH est possible d'au moins trois façons :

avec scp (comme Ssh CoPy), qui s'utilise de la même manière que la commande cp ;
avec sftp, logiciel très basique qui s'utilise comme ftp.
avec lftp, dont je vous avais déjà parlé au Chapitre 22 pour les transferts de fichiers par FTP.

Ici également, vous pouvez utiliser la méthode d'authentification par mot de passe ou par clefs, l'utilisation restant la même dans les deux cas.

Utiliser SCP

Pour illustrer la syntaxe, je vais vous donner quelques exemples :

pour transférer le fichier test1.txt situé dans le répertoire courant vers le home du compte toto de la machine ordi1.exemple.org sur laquelle tourne un serveur SSH :
```
% scp test1.txt toto@ordi1.exemple.org:
```
pour récupérer le fichier test2.txt situé dans le répertoire personnel de l'utilisateur toto de la machine ordi2.exemple.org et l'écrire dans le répertoire courant :
```
% scp toto@ordi2.exemple.org:test2.txt .
```
pour récupérer tous les fichiers ayant l'extension .txt situés dans le répertoire /usr/local de la machine ordi2.exemple.org et l'écrire dans le sous-répertoire test-scp du répertoire courant :
```
% scp toto@ordi2.exemple.org:'/usr/local/*.txt' test-scp
```
pour transférer l'intégralité du sous-répertoire test-scp du répertoire courant vers le sous répertoire incoming du home de l'utilisateur toto de la machine ordi1.exemple.org :
```
% scp -r test-scp toto@ordi1.exemple.org:incoming
```

Utiliser lftp

Je vous avais déjà parlé de l'utilisation de lftp comme client FTP dans la section Le ftp en console. Mais ce que je ne vous avais pas dit, c'est que lftp sait aussi transférer des fichiers par SSH !

Pour l'installation et la configuration de lftp, reportez-vous à la section Le ftp en console.

Pour se connecter par SSH en utilisateur toto sur le serveur ordi1.exemple.org :

% lftp sftp://toto@ordi1.exemple.org

Ensuite, les commandes sont exactement les mêmes que lors de l'utilisation de lftp comme client FTP !

5.2. En graphique

GNOME permet de se connecter à un serveur SSH directement dans Nautilus. Comme pour FTP, cela permet d'accéder aux fichiers distants depuis toutes les applications GNOME.

Pour cela, allez dans le menu Raccourcis > Se connecter à un serveur, puis choisissez SSH, et réglez les paramètres de connexion (Figure 40.1).

Figure 40.1. Connexion à un serveur SSH

6. Se connecter par SSH sans taper de mot de passe

6.1. Le principe

Cette section s'adresse à ceux qui utilisent un couple de clefs publiques / privées, et qui ont chiffré leur clé privée avec une pass phrase (c'est la configuration la plus sûre). Par conséquent, le client SSH demande la pass phrase à chaque utilisation des clefs pour s'authentifier.

Pour éviter d'avoir à taper systématiquement sa pass phrase, il faut utiliser ssh-agent : ce programme tourne en tâche de fond et garde la clef en mémoire. La commande ssh-add permet de donner sa clef à ssh-agent. Ensuite, quand vous utilisez le client SSH, il contacte ssh-agent pour qu'il lui donne la clef.

6.2. La pratique

en console

Dans une console, lancez ssh-agent en évaluant les commandes qu'il écrit sur sa sortie :

% eval $(ssh-agent)

Puis donnez votre clef à l'agent :

% ssh-add

Il vous demande alors votre pass phrase. Maintenant que votre clef a été transmise à l'agent, vous pouvez vous connecter sans entrer de mot de passe à toutes les machines pour lesquelles vous avez mis votre clef publique dans le fichier ~/.ssh/authorized_keys.

en mode graphique

Si vous utilisez GDM, l'agent SSH a déjà été lancé par GDM. Vous n'avez donc plus qu'à exécuter ssh-add une fois que vous êtes connecté.

7. Faire des tunnels SSH

Faire un tunnel SSH est un moyen simple de chiffrer n'importe quelle communication TCP entre votre machine et une machine sur laquelle vous avez un accès SSH.

Par exemple, pour établir un tunnel SSH pour une connexion HTTP vers la machine serveur.exemple.org :

% ssh -L 2012:serveur.exemple.org:80 toto@serveur.exemple.org

où 2012 est le port sur la machine cliente à partir duquel la connexion entre dans le tunnel SSH (le port doit être supérieur à 1024 si on ne veut pas avoir à lancer le tunnel en tant que root, et le pare-feu ne doit pas bloquer ce port).

Ensuite, il suffit de lancer un navigateur Web en lui demandant de se connecter en local sur ce port :

% w3m http://localhost:2012

Figure 40.2. Exemple de tunnel SSH

8. Et le bon vieux Telnet ?

8.1. Qu'est-ce que Telnet ?

Telnet, c'est comme SSH… mais en moins bien ! Telnet est un protocole qui permet d'accéder à distance à une machine, mais la connexion n'est pas sécurisée : le mot de passe et les données sont transférés en clair ! Il est donc conseillé de ne pas utiliser Telnet mais uniquement SSH.

8.2. Client et serveur Telnet

Le client Telnet se trouve dans le paquet telnet. Ce paquet est installé par défaut.

Le serveur Telnet se trouve dans le paquet telnetd. Il n'y a aucune configuration à faire.

Pour se connecter à un serveur Telnet, tapez :

% telnet nom_DNS_du_serveur_telnet

et ensuite rentrez votre login et votre mot de passe quand il vous le demande.

Précédent	Niveau supérieur	Suivant
Chapitre 39. Monter un pont réseau	Sommaire	Chapitre 41. Transférer des fichiers