Chapitre 1. L'accès à distance par SSH
- Table des matières
- 1. Introduction et mise-en-garde
- 2. Le système de clés de SSH
- 3. Installation et configuration de SSH
- 4. Se logguer par SSH
- 5. Transfert de fichiers par SSH
- 5.1. En console
- 5.2. En graphique
- 6. Se logguer par SSH sans taper de mot de passe
- 6.1. Le principe
- 6.2. La pratique
- 7. Faire des tunnels SSH
- 8. Et le bon vieux Telnet... ?
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. crypté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é
1.2.1. 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 clés). 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 Le réseau et la sécurité ;
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.
1.2.2. 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 Lmjycr2r!
1.2.3. 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, le root peut donc installer le programme john et le lancer sur le fichier /etc/shadow :
# apt-get install john # john /etc/shadow |
Quand john a trouvé un mot de passe, il l'affiche avec le login associée.
Attention, john utilisera le processeur à 100 % ! Il est donc conseillé de lui donner un 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 clés de SSH
2.1. 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 clé : une clé publique et une clé privée. La clé publique peut être librement publiée tandis que la clé privée doit rester secrète. La connaissance de la clé publique ne permet pas d'en déduire la clé privée.
Si la personne A veut envoyer un message confidentiel à la personne B, A crypte le message avec la clé publique de B et l'envoie à B sur un canal qui n'est pas forcément sécurisé. Seul B pourra décrypter le message en utilisant sa clé privée.
2.2. La théorie de la cryptographie symétrique
SSH utilise également la cryptographie symétrique. Son principe est simple : si A veut envoyer un message confidentiel à B, A et B doivent d'abord posséder une même clé secrète. A crypte le message avec la clé secrète et l'envoie à B sur un canal qui n'est pas forcément sécurisé. B décrypte le message grâce à la clé secrète. Toute autre personne en possession de la clé secrète peut décrypter le message.
La cryptographie symétrique est beaucoup moins gourmande en ressources processeur que la cryptographie asymétrique... mais le gros problème est l'échange de la clé secrète entre A et B. 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 A et B puissent s'échanger une clé 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 clé secrète échangée.
Pour plus d'informations sur la cryptographie, je vous conseille la lecture du dossier consacré à ce sujet par le magazine pour la science dans son hors-série de Juillet-Octobre 2002.
2.3. L'établissement d'une connexion SSH
Un serveur SSH dispose d'un couple de clés 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 clé privée et a les permissions 600. Le fichier ssh_host_rsa_key.pub contient la clé publique et a les permissions 644.
Nous allons suivre par étapes l'établissement d'une connexion SSH :
Le serveur envoie sa clé publique au client.
Le client génère une clé secrète et l'envoie au serveur, en cryptant l'échange avec la clé publique du serveur (cryptographique asymétrique). Le serveur décrypte la clé secrète en utilisant sa clé privée, ce qui prouve qu'il est bien le vrai serveur.
Pour le prouver au client, il crypte un message standard avec la clé secrète et l'envoie au client. Si le client retrouve le message standard en utilisant la clé secrète, il a la preuve que le serveur est bien le vrai serveur.
Une fois la clé secrète échangée, le client et le serveur peuvent alors établir un canal sécurisé grâce à la clé secrète commune (cryptographie 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éloggue.
La seule contrainte est de s'assurer que la clé publique présentée par le serveur est bien sa clé 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 clé publique du serveur avant de s'y connecter pour la première fois. Le fingerprint d'une clé publique est une chaîne de 32 caractères hexadécimaux unique pour chaque clé ; il s'obtient grâce à la commande ssh-keygen -l.
3. Installation et configuration de SSH
3.1. Installation du client et du serveur SSH
Le client et le serveur SSH sont dans le même package ssh. Ce package est installé dès la première utilisation de dselect. Si vous avez bien respecté nos consignes lors de la procédure d'installation (chapitre Les packages) vous n'avez pas activé le serveur SSH.
Maintenant que votre système est à jour niveau sécurité, vous pouvez activer le serveur SSH, si vous le souhaitez. Pour cela, supprimez le fichier /etc/ssh/sshd_not_to_be_run et lancer SSH :
# rm /etc/ssh/sshd_not_to_be_run # /etc/init.d/ssh start Starting OpenBSD Secure Shell server: sshd. |
3.2. Configuration du serveur SSH
Le fichier de configuration du serveur SSH est /etc/ssh/sshd_config. A 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.
Protocol 2
Signifie que votre serveur SSH accepte uniquement la version 2 du protocole SSH. C'est une version plus sécurisée que la version 1 du protocole. Seuls certains vieux clients SSH ne savent faire que du SSH version 1. Si vous voulez que le serveur accepte les deux protocoles, changez la ligne en :
Protocol 2,1
PermitRootLogin yes
Signifie que vous pouvez vous logguer 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. C'est une sorte de double protection.
X11Forwarding yes
Signifie que vous allez pouvoir travailler en export display par SSH. Ce sera expliqué plus tard, dans la troisième partie de cette formation Faire de l'export display.
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 logguer 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 |
Si c'est la première connexion SSH depuis ce client vers ce serveur, il vous demande si le fingerprint de la clé 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 clé publique et la comparer à celle qu'il vous affiche. Si les deux fingerprints sont identiques, répondez yes, et la clé 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 clé 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 loggué en local sur la machine.
4.2. Authentification par clé
Au lieu de s'authentifier par mot de passe, les utilisateurs peuvent s'authentifier grâce à la cryptographie asymétrique et son couple de clés privée/publique, comme le fait le serveur SSH auprès du client SSH.
4.2.1. Générer ses clés
Pour générer un couple de clés DSA, tapez :
% ssh-keygen -t dsa |
Les clés 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.
Par défaut (il demande confirmation lors du processus de création), la clé privée est stockée dans le fichier ~/.ssh/id_dsa avec les permissions 600 et la clé publique est stockée dans le fichier ~/.ssh/id_dsa.pub avec les permissions 644.
Lors de la création, il vous demande une pass phrase qui est un mot de passe pour protéger la clé privée. Cette pass phrase sert à crypter la clé privée. La pass phrase vous sera alors demandée à chaque utilisation de la clé privée, c'est à dire à chaque fois que vous vous logguerez en utilisant cette méthode d'autentification. 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.
 | Vous pouvez à tout moment changer la pass phrase qui protège votre clé privée avec la commande ssh-keygen -p. |
4.2.2. Autoriser votre clé publique
Pour cela, il suffit de copier votre clé publique dans le fichier ~/.ssh/authorized_keys de la machine sur laquelle vous voulez vous logguer à 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 |
et entrez le mot de passe de votre compte sur le serveur.
4.2.3. Se logguer
La commande est la même que pour une autentification par mot de passe.
5. Transfert de fichiers par SSH
5.1. En console
Le transfert de fichiers par SSH est possible de deux façons :
avec scp (comme Ssh CoPy), qui s'utilise la même manière que la commande cp ;
avec yafc, dont je vous avais déjà parlé au chapitre Le Web et le FTP en console pour les transferts de fichiers par FTP.
Encore une fois, vous pouvez utiliser la méthode d'autentification par mot de passe ou par clés, l'utilisation est la même.
5.1.1. Utiliser SCP
Pour illustrer la syntaxe, je vais 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é le home 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
5.1.2. Utiliser yafc
Je vous avais déjà parlé d'utilisation de yafc comme client FTP dans la section Le FTP en console. Mais ce que je ne vous avais pas dit, c'est que yafc sait aussi transférer des fichiers par SSH !
Pour l'installation et la configuration de yafc, reportez-vous à la section Le FTP en console.
Pour se connecter par SSH en utilisateur toto sur le serveur ordi1.exemple.org :
% yafc ssh://toto@ordi1.exemple.org |
Ensuite, les commandes sont exactement les mêmes que lors de l'utilisation de yafc comme client FTP !
5.2. En graphique
gFTP, dont l'installation est expliquée à la fin du chapitre Le Web, le mail et les news en mode graphique fait également office de client SFTP.
Lançez gFTP avec la commande gftp. Ensuite, allez dans le menu FTP / Options, sélectionnez l'onglet SSH, mettez le paramètre Chemin sftp-server SSH2 à /usr/lib/ et cliquez sur Enregistrez.
Pour vous connecter, entrez le nom DNS du serveur ainsi que le login et le mot de passe, sélectionnez SSH2 à la place de FTP dans la liste déroulante et tapez Entrée.
6. Se logguer par SSH sans taper de mot de passe
6.1. Le principe
Cette section s'adresse à ceux qui utilisent un couple de clés publiques / privées, et qui ont crypté 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 clés pour s'autentifier.
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 clé à ssh-agent. Ensuite, quand vous utilisez le client SSH, il contacte ssh-agent pour qu'il lui donne la clé.
6.2. La pratique
6.2.1. en console
Dans une console, ouvrez un screen avec ssh-agent en tâche de fond :
% ssh-agent screen |
Puis donnez votre clé à l'agent :
% ssh-add |
Il vous demande alors votre pass phrase. Maintenant que votre clé a été transmise à l'agent, vous pouvez vous connecter sans entrer de mot de passe à toutes les machines pour lesquelles vous avez mis votre clé publique dans le fichier ~/.ssh/authorized_keys.
6.2.2. en mode graphique
Démarrez le serveur graphique avec la commande :
% ssh-agent startx |
Puis ouvrez un xterm et tapez :
% ssh-add |
L'agent sera alors actif pour toutes les applications que vous utiliserez en mode graphique, et notamment tous les xterm ouverts ou que vous ouvrirez.
6.2.3. avec GDM
Si vous utilisez GDM, l'agent SSH a déjà été lançé par GDM. Vous n'avez donc plus qu'à exécuter ssh-add une fois que vous êtes loggué.
7. Faire des tunnels SSH
Faire un tunnel SSH est un moyen simple de crypter 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 à lançer le tunnel en tant que root).
Ensuite, il suffit de lançer un navigateur Web en lui demandant de se connecter en local sur ce port :
% w3m http://localhost:2012 |
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 ! Telnet ne permet pas de faire des transferts de fichiers. 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 package telnet. Ce package est installé par défaut.
Le serveur Telnet se trouve dans le package 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.