Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Installation et configuration d'un serveur internet
  3. Secure Shell (SSH)
Extrait - Installation et configuration d'un serveur internet (BIND, Apache, Nginx, Dovecot, Postfix...)
Extraits du livre
Installation et configuration d'un serveur internet (BIND, Apache, Nginx, Dovecot, Postfix...)
2 avis
Revenir à la page d'achat du livre

Secure Shell (SSH)

Introduction

Secure Shell est un protocole réseau pour créer des connexions sécurisées. Dans sa forme la plus originelle et pure, SSH est employé pour lancer un terminal à distance pour exécuter des commandes. Le protocole sert cependant également au transfert des fichiers (SCP, SFTP) mais aussi comme protocole de transport pour d’autres protocoles, typiquement des protocoles moins fortement sécurisés, ainsi qu’au réacheminement de port (en anglais : port forwarding) - le renvoi des requêtes de certains ports vers des ports sur d’autres serveurs - une technique souvent employée pour permettre la communication entre machines des différents côtés d’un pare-feu.

Pour l’administrateur Unix, SSH est un outil indispensable pour l’administration à distance ; les clients et les serveurs SSH existent pour quasiment tous les systèmes d’exploitation et sont installés par défaut sur presque tous les systèmes Unix.

Le daemon SSH s’appelle sshd, le client terminal s’appelle ssh ; les clients pour le transfert de fichiers s’appellent scp et sftp.

Pour permettre une connexion SSH au serveur, le pare-feu doit être configuré pour autoriser le trafic réseau entrant sur le port TCP 22.

Installation et configuration du serveur SSH

Plusieurs serveurs SSH existent. Le serveur de loin le plus utilisé est OpenSSH, un paquet développé par quelques développeurs OpenBSD, qui se compose d’un serveur et d’un client SSH et des outils pour le transfert de fichiers et la gestion des clés SSH. L’OpenSSH Portability Team (équipe portabilité d’OpenSSH) suit le développement d’OpenSSH et adapte le code source pour permettre la mise en œuvre sur un grand nombre de systèmes d’exploitation.

1. Installation FreeBSD

Bien qu’il existe des paquetages et des ports, OpenSSH fait partie du système de base, il n’est donc pas nécessaire de l’installer explicitement.

Si jamais le paquetage ou le logiciel porté est installé comme dépendance d’un autre paquetage, par exemple, cela ne posera aucun problème : la version originelle est installée dans /usr/bin et le paquetage et le logiciel porté sont installés dans /usr/local/bin ; les deux versions peuvent coexister sans problème. Si la configuration du système n’est pas modifiée, la version du système de base sera utilisée.

Pour remplacer la version du système de base par le paquetage ou par le logiciel porté, par exemple pour profiter des fonctionnalités optionnelles présentes dans le catalogue des logiciels portés, voici les étapes à suivre :

1. Installer le logiciel porté.

2. Arrêter le daemon SSH.

freebsd# service sshd stop 

3. Modifier ou définir deux variables dans le fichier /etc/rc.conf :

sshd_enable="NO" 
openssh_enable="YES" 

4. Lancer le daemon OpenSSH.

freebsd# service openssh start 

5. Ouvrir une nouvelle session SSH, SANS couper la session ouverte.

6. Si la nouvelle session ne pose pas de problèmes, la première session peut être fermée.

Arrêter le daemon (Open)SSH ne coupera pas les connexions existantes. Il est important de vérifier le fonctionnement du daemon qui vient d’être installé avant de couper la connexion avec l’ancien daemon ; en effet, si le nouveau daemon pose problème, la connexion existante sera souvent le seul chemin pour réparer les problèmes. Après avoir...

Lancement d’une session

Les sections suivantes expliquent comment se connecter par SSH au serveur depuis un ordinateur Unix ou Windows. Qu’importe le système client utilisé, la première fois qu’un utilisateur se connecte au serveur, il est censé accepter une host key fingerprint (empreinte de clé d’hôte). Cette empreinte digitale est une chaîne de caractères unique qui permet de vérifier l’identité du serveur (ou, en fait, l’identité de la clé cryptographique utilisée par le serveur pour chiffrer la connexion).

Bien qu’il ne soit pas évident de vérifier cette empreinte - elle se compose d’une longue chaîne de caractères apparemment aléatoires - il est important de le faire malgré tout pour s’assurer que le serveur est vraiment le serveur qu’il prétend être. Cette vérification n’est nécessaire qu’une seule fois, sauf si le serveur change d’adresse IP, de nom d’hôte ou de clé ; le client SSH enregistre la combinaison de l’adresse IP et de l’empreinte dans le fichier ~/.ssh/known_hosts.

L’administrateur du serveur peut fournir les empreintes utilisées par le serveur, pour vérification ; il est recommandé d’envoyer ces empreintes à chaque nouvel utilisateur. La liste d’empreintes...

Transfert de fichiers par une connexion SSH

À part l’ouverture d’un terminal à distance, le protocole SSH sert également au transfert de fichiers. SCP et SFTP sont deux protocoles de transfert de fichiers basés sur SSH.

1. SFTP

L’utilisation de SFTP (en anglais : SSH File Transfer Protocol, protocole de transfert de fichiers par SSH) est comparable à celle de FTP : un client se connecte au serveur, permettant à l’utilisateur de gérer interactivement les fichiers sur le serveur, et entre le client et le serveur, jusqu’à ce que la connexion soit coupée.

Comme indiqué plus haut, l’option Subsystem sftp doit être activée dans la configuration de sshd pour pouvoir profiter de SFTP.

$ sftp dimitri@vert.example.com 
sftp> pwd 
Remote working directory: /home/dimitri 
sftp> ls 
bin  Documents  logo.png    Téléchargements  todo.txt 
sftp> get logo.png 
Fetching /home/dimitri/logo.png to logo.png 
/home/dimitri/logo.png        100%    621 6.2KB/s    00:00 
sftp> exit 
$ 

La commande sftp charge aussi la configuration de SSH, donc si le fichier ~/.ssh/config de l’utilisateur contient la définition Host décrite précédemment, il peut...

Clé SSH au lieu de mot de passe

Les bons mots de passe sont difficiles à retenir. Et, bien sûr, les mauvais mots de passe représentent des risques de sécurité. Le SSH sait contourner ces problèmes à l’aide des paires de clés cryptographiques.

En cryptographie, une paire de clés se compose de deux clés virtuelles, l’une s’appelle la clé privée (en anglais : private key) et l’autre s’appelle la clé publique (en anglais : public key). Les messages qui ont été cryptés avec la clé publique ne peuvent être décryptés qu’avec la clé privée ; toute personne possédant une clé publique peut alors crypter un message, le propriétaire de la clé privée correspondante est la seule personne qui peut décrypter ce message.

Un message peut également être signé avec la clé privée, et ensuite, la clé publique peut servir à vérifier cette signature numérique, donc l’identité de l’expéditeur du message ; la clé publique peut aussi servir à vérifier si le message a été modifié entre le moment où l’expéditeur l’a signé et le moment de vérification de la signature. Évidemment, le propriétaire est censé garder en sécurité la clé privée et la protéger avec un mot de passe. Ce système à deux clés s’appelle la cryptographie asymétrique.

Le SSH sait se servir de cette forme de cryptographie pour l’authentification d’utilisateurs. L’utilisateur peut générer une paire de clés et enregistrer la clé publique dans son répertoire personnel sur le serveur (ou demander à l’administrateur système de le faire). Quand l’utilisateur se connecte au serveur, au lieu d’un mot de passe, le client SSH envoie au serveur un message signé avec la clé privée de l’utilisateur ; si la signature correspond à la clé publique enregistrée sur le serveur, l’utilisateur est autorisé à avoir l’accès. Bien que l’utilisateur doive...