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
:
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 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.
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>
.
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.
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.
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 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.
%
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 ESMTPCeci 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 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
.
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.
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>.