Séquence des événements d'une connexion SSH

Pour aider à protéger l'intégrité d'une communication SSH entre deux ordinateurs hôtes, une certaine série d'événements doit être utilisée.

D'abord, une couche transport sécurisée doit être créée pour que le client sache qu'il communique bien avec le bon serveur. Ensuite, la communication est chiffrée entre le client et le serveur au moyen d'un chiffre symétrique.

Puis, une fois la connexion sécurisée établie avec le serveur, le client peut s'authentifier auprès de celui-ci sans craindre que ses informations ne puissent être compromises. Sur Red Hat Linux, OpenSSH utilise par défaut des clés DSA ou RSA et la version 2.0 du protocole SSH pour l'authentification.

Enfin, après l'authentification du client auprès du serveur, de nombreux services différents peuvent être utilisés de façon sécurisée au cours de la connexion, tels qu'une session shell interactive, des applications X11 et des ports TCP/IP tunnellisés.

L'ensemble du processus de connexion se fait sans que le système local n'ait à faire de nombreuses opérations supplémentaires. En effet, SSH semblera familier, à bien des égards, aux utilisateurs habitués aux méthodes de connexion moins sécurisées.

Dans l'exemple qui suit, l'utilisateur 1 (user1) sur le système client veut initier une connexion SSH à un système serveur. L'adresse IP de ce serveur est 10.0.0.2, mais on pourrait également utiliser son nom de domaine. Le nom de connexion de l'utilisateur 1 sur le serveur est user2. La commande ssh est écrite de la façon suivante :

[user1@machine1 user1]$ ssh user2@10.0.0.2

Le client OpenSSH demande la phrase d'accès de la clé privée de l'utilisateur pour déchiffrer la clé privée utilisée pour procéder à l'authentification. Cependant, la phrase d'accès de la clé privée n'est pas envoyée au moyen de la connexion sécurisée en cours entre le client et le serveur. Elle est plutôt utilisée pour ouvrir le fichier id_dsa et générer une signature qui est ensuite envoyée au serveur. Si le serveur a une copie de la clé publique de l'utilisateur pouvant être utilisée pour vérifier la signature, l'utilisateur est alors authentifié.

Dans cet exemple, l'utilisateur utilise une clé DSA (des clés RSA, notamment, peuvent aussi être utilisées) et reçoit l'invite suivante :

Enter passphrase for DSA key '/home/user1/.ssh/id_dsa':

Si l'authentification par clé publique échoue, pour une raison ou une autre (il se pourrait que la phrase d'accès ait été mal tapée ou que les renseignements d'authentification n'existent pas encore sur le serveur), un autre type d'authentification est généralement lancé. Dans notre exemple, le serveur OpenSSH permet à l'utilisateur 1 de s'authentifier au moyen du mot de passe de l'utilisateur 2 (user2) car la signature envoyée ne correspond pas à la clé publique stockée par l'utilisateur 2 :

user2@machine2's password:

En introduisant le bon mot de passe, l'utilisateur reçoit une invite shell. Bien entendu, l'utilisateur 2 doit déjà avoir un compte sur l'ordinateur 10.0.0.2 pour que l'authentification par mot de passe réussisse.

Last login: Mon Apr 15 13:27:43 2001 from machine1
[user2@machine2 user2]$ 

A ce stade, l'utilisateur peut interagir avec le shell de la même façon qu'avec telnet ou rsh, sauf que la communication est chiffrée.

D'autres outils SSH, tels que scp et sftp, fonctionnent de façon semblable aux outils non sécurisés rcp et ftp. Veuillez lire le Guide de personnalisation officiel Red Hat Linux pour avoir des instructions et des exemples sur l'utilisation de ces outils et d'autres commandes SSH.