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.
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.
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.
L'utilitaire ssh(1) fonctionne de la même manière que rlogin(1):
# ssh [email protected] 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. [email protected]'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.
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 [email protected]:/COPYRIGHT COPYRIGHT [email protected]'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>.
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.
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 rsa1cré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).
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 [email protected] %
La commande ssh est utilisée avec les options suivantes:
-2Force ssh à utiliser la version du protocole (à ne pas utiliser si vous travaillez avec de vieux serveurs SSH).
-NN'exécute aucune commande à distance, ou mode se place en mode tunnel. Si cette option est omise ssh initiera une session normale.
-fForce ssh à s'exécuter en arrière-plan.
-LSpécifie un tunnel local de la manière port_local:machine_distante:port_distant.
[email protected]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 [email protected] [email protected]'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é.
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 [email protected] [email protected]'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.
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 [email protected] [email protected]'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.
| Précédent | Sommaire | Suivant |
| IPsec | Niveau supérieur | 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.FreeBSD.org/pub/FreeBSD/doc/.
Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <[email protected]>.
Pour les questions sur cette documentation, contactez <[email protected]>.