14.11. OpenSSH
Précédent | Chapitre 14. Sécurité | Suivant

## 14.11. OpenSSH

Contribution de Chern Lee.

OpenSSH est un ensemble d'outils de connexion réseau utilisés pour accéder à des machines distantes de façon sécurisée. Ils peuvent être utilisés comme remplaçants directs de `rlogin`, `rsh`, `rcp`, et `telnet`. De plus, OpenSSH peut sécuriser n'importe quelle connexion TCP/IP via un tunnel. OpenSSH chiffre tout le trafic de façon à déjouer les écoutes réseau, les prises de contrôle de connexion, et aux attaques au niveau du réseau.

OpenSSH est maintenu par le projet OpenBSD, et est basé sur SSH v1.2.12 avec tous les récentes corrections et mises à jour. Il est compatible avec les protocoles SSH 1 et 2. OpenSSH est présent dans le système de base depuis FreeBSD 4.0.

### 14.11.1. Les avantages à utiliser OpenSSH

Normalement, quand on utilise telnet(1) ou rlogin(1), les données sont envoyées sur le réseau en clair, sous forme non chiffrée. Des “renifleurs de paquets” placés n'importe où entre le client et le serveur peuvent prendre connaissance de votre nom d'utilisateur, de votre mot de passe et des données transmises lors de votre session. OpenSSH offre une variété de méthodes d'authentification et de chiffrage pour éviter ce genre de problème.

### 14.11.2. Activer sshd

Assurez-vous d'ajouter la ligne suivante à votre fichier `rc.conf`:

    sshd_enable="YES"

Cela chargera le “daemon” ssh à l'initialisation suivante du système. Alternativement, vous pouvez tout simplement exécuter le “daemon” sshd directement en tapant `sshd` sur la ligne de commande.

### 14.11.3. Client SSH

L'utilitaire ssh(1) fonctionne de la même manière que rlogin(1):

    # ssh user@example.com
    Host key not found from the list of known hosts.
    Are you sure you want to continue connecting (yes/no)? yes
    Host 'example.com' added to the list of known hosts.
    user@example.com's password: *******

L'ouverture de session se poursuit comme si elle avait lancée par rlogin(1) ou telnet(1). Le système SSH utilise un système d'empreinte de clé pour vérifier l'authenticité du serveur quand le client se connecte. L'utilisateur est invité à entrer `yes` uniquement à la première connexion. Lors des futures connexions, l'empreinte de la clé sauvegardé est vérifiée. Le client SSH vous avertira si l'empreinte sauvée diffère de l'empreinte reçue lors de futures tentatives de connexion. Les empreintes sont sauvées dans le fichier `~/.ssh/known_hosts`, ou `~/.ssh/known_hosts2` pour les empreintes du protocole SSH 2.

Par défaut, les serveurs OpenSSH sont configurés pour accepter les connexions dans les deux protocoles SSH 1 et 2. Le client peut, cependant, choisir entre les deux. Le protocole 2 est connu pour être plus robuste et plus sécurisé que son prédécesseur.

`ssh` peut être forcé à utilisé l'un des protocole en passant l'argument `-1` ou `-2` pour le protocole 1 ou 2 respectivement.

### 14.11.4. Copie sécurisée

La commande scp(1) fonctionne de la même manière que rcp(1); elle copie un fichier vers ou à partir d'une machine distante à la différence qu'elle le fait d'une façon sécurisé.

    #  scp user@example.com:/COPYRIGHT COPYRIGHT
    user@example.com's password: *******
    COPYRIGHT            100% |*****************************|  4735
    00:00
    #

Puisque l'empreinte a déjà été sauvée pour cette machine dans l'exemple précédent, cela se vérifie ici quand on utilise scp(1).

Les arguments passés à scp(1) sont similaires à ceux de cp(1), avec le ou les fichiers en premier argument, et la destination en second. Puisque que le fichier est copié via le réseau, par l'intermédiaire de SSH, un ou plusieurs des arguments prennent la forme `utilisateur@machine_distante:<chemin_du_fichier>`.

### 14.11.5. Configuration

Les fichiers de configuration général au système pour le “daemon” et le client OpenSSH résident dans le répertoire `/etc/ssh`.

`ssh_config` permet de paramétrer le client, tandis que `sshd_config` s'occupe de la configuration du “daemon”.

De plus, les options `sshd_program` (`/usr/sbin/sshd` par défaut), et `sshd_flags` du fichier `rc.conf` peut fournir un niveau supplémentaire de configuration.

### 14.11.6. ssh-keygen

Au lieu d'utiliser des mots de passe, ssh-keygen(1) peut être employé pour générer des clés RSA pour authentifier un utilisateur:

    % ssh-keygen -t rsa1
    Initializing random number generator...
    Generating p:  .++ (distance 66)
    Generating q:  ..............................++ (distance 498)
    Computing the keys...
    Key generation complete.
    Enter file in which to save the key (/home/user/.ssh/identity):
    Enter passphrase:
    Enter the same passphrase again:
    Your identification has been saved in /home/user/.ssh/identity.
    ...

ssh-keygen(1) créera une paire de clés publique et privée à utiliser pour l'authentification. La clé privée est stockée dans le fichier `~/.ssh/identity`, alors que la clé publique l'est dans le fichier `~/.ssh/identity.pub`. La clé publique doit être placée dans le fichier `~/.ssh/authorized_keys` sur la machine distante pour que cela fonctionne.

Ceci autorisera les connexions sur la machine distante en utilisant l'authentification RSA à la place des mots de passe.

### Note:

L'option `-t rsa1` créera des clés RSA pour le protocole SSH 1. Si vous désirez utiliser des clés RSA avec le protocole SSH 2, vous devez employer la commande `ssh-keygen -t rsa`.

Si une phrase d'authentification est utilisée avec ssh-keygen(1), l'utilisateur se verra demandé d'entrer un mot de passe à chaque utilisation de la clé privé.

Une clé DSA SSH protocole 2 peut être créée pour le même objectif en utilisant la commande `ssh-keygen -t dsa`. Cela créera une paire de clés DSA pour les sessions SSH utilisant le protocole 2. La clé publique est conservée dans `~/.ssh/id_dsa.pub`, tandis que la clé privée se trouve dans `~/.ssh/id_dsa`.

Les clés publiques DSA sont placées dans le fichier `~/.ssh/authorized_keys` sur la machine distante.

ssh-agent(1) et ssh-add(1) sont des utilitaires employés pour la gestion de multiples clés privées protégées par mots de passe.

### Avertissement:

Les divers fichiers et options peuvent être différents selon la version d'OpenSSH dont vous disposez, pour éviter les problèmes vous devez consultez la page de manuel ssh-keygen(1).

### 14.11.7. Tunnels SSH

OpenSSH a la capacité de créer un tunnel pour encapsuler un autre protocole dans une session chiffrée.

La commande suivante demande à ssh(1) de créer un tunnel pour telnet:

    % ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com
    %

La commande `ssh` est utilisée avec les options suivantes:

`-2`

  Force `ssh` à utiliser la version du protocole (à ne pas utiliser si vous travaillez avec de vieux serveurs SSH).

`-N`

  N'exécute aucune commande à distance, ou mode se place en mode tunnel. Si cette option est omise `ssh` initiera une session normale.

`-f`

  Force `ssh` à s'exécuter en arrière-plan.

`-L`

  Spécifie un tunnel local de la manière `port_local:machine_distante:port_distant`.

`user@foo.example.com`

  Le serveur SSH distant.

Un tunnel SSH fonctionne grâce à l'allocation d'une “socket” qui écoute sur le port spécifié de la machine `localhost`. Il transfère ensuite toute connexion reçue sur la/le machine/port local(e) via la connexion SSH vers la machine et le port distants spécifiés.

Dans l'exemple, le port `5023` sur la machine locale transfère toute connexion sur ce port vers le port `23` de la machine distante (le `localhost` de la commande). Puisque le port `23` est celui de telnet, cela créerai une session telnet sécurisée par l'intermédiaire d'un tunnel SSH.

Cela peut être utilisé pour encapsuler n'importe quel nombre de protocoles TCP non sécurisé comme SMTP, POP3, FTP, etc.

Exemple 14.1. Utiliser SSH pour créer un tunnel sécurisé pour SMTP

    % ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
    user@mailserver.example.com's password: *****
    % telnet localhost 5025
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    220 mailserver.example.com ESMTP

Ceci peut être utilisé en conjonction avec ssh-keygen(1) et des comptes utilisateurs supplémentaires pour la création et l'accès au tunnel SSH sans trop de problème. Des clés peuvent être utilisées à la place de la saisie d'un mot de passe, et les tunnels peuvent être exécutés sous un utilisateur séparé.

#### 14.11.7.1. Exemples pratiques de tunnels SSH

##### 14.11.7.1.1. Accès sécurisé à un serveur POP3

Au travail, il y a un serveur SSH qui accepte les connexions de l'extérieur. Sur le même réseau d'entreprise réside un serveur de courrier électronique faisant fonctionner un serveur POP3. Le réseau ou le chemin entre chez vous et le bureau peut ou peut ne pas être complètement sûr. Pour cette raison, vous devez récupérer votre courrier électronique d'une façon sécurisée. La solution est de créer une connexion SSH vers le serveur SSH de votre entreprise, et d'utiliser ce tunnel vers le serveur de courrier.

    % ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
    user@ssh-server.example.com's password: ******

Quand le tunnel est configuré et fonctionne, vous pouvez demander à votre client de courrier électronique d'envoyer ses requêtes POP3 sur le port 2110 de la machine locale: `localhost`. Les connexions seront transférées de façon sécurisé à travers le tunnel jusqu'à `mail.example.com`.

##### 14.11.7.1.2. Passer à travers un coupe-feu restrictif

Certains administrateurs réseau imposent des règles draconiennes au niveau du coupe-feu, filtrant non seulement les connexions entrantes, mais également les connexions sortantes. Il se peut que vous n'ayez accès qu'aux ports 22 et 80 de machines distantes pour SSH ou la navigation Internet.

Vous pouvez vouloir accéder à un autre (n'ayant peut-être aucun rapport avec votre travail) service, comme un serveur Ogg Vorbis pour écouter de la musique. Si le serveur Ogg Vorbis diffuse (“streaming”) ses données à partir d'un port différent des ports 22 ou 80, vous ne serez alors pas en mesure d'y accéder.

La solution est de créer une connexion SSH vers une machine à l'extérieur du réseau protégé par le coupe-feu, et l'utiliser pour créer un tunnel vers le serveur Ogg Vorbis.

    % ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org
    user@unfirewalled-system.example.org's password: *******

Vous pouvez maintenant faire pointer votre client pour la récupération du flux de données sur le port 8888 de la machine locale, qui sera transféré jusqu'au port 8000 de la machine `music.example.com`, passant ainsi outre les restrictions du coupe-feu.

### 14.11.8. Lectures supplémentaires

OpenSSH

ssh(1) scp(1) ssh-keygen(1) ssh-agent(1) ssh-add(1)

sshd(8) sftp-server(8)

Précédent | Niveau supérieur | Suivant
14.10. IPsec | Sommaire | 14.12. Listes de contrôle d'accès au système de fichiers

Ce document, ainsi que d'autres peut être téléchargé sur ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.