Le paquetage OpenSSH est installé par défaut sous SUSE Linux. Vous disposez ainsi des programmes ssh, scp et sftp, afin de remplacer telnet, rlogin, rsh, rcp et ftp. Dans la configuration par défaut, l'accès à un système SUSE Linux n'est possible qu'avec les utilitaires OpenSSH et uniquement si le pare-feu autorise l'accès.

Le programme ssh permet de se connecter à un système distant et d'y travailler de façon interactive. Il constitue ainsi une alternative à telnet et à rlogin. Le programme slogin n'est qu'un lien symbolique faisant référence à ssh. Ainsi, la commande ssh sun permet de se connecter sur la machine sun. L'hôte invite alors à entrer le mot de passe pour le système sun.

Une fois authentifié, vous pouvez alors y travailler soit à partir de la ligne de commande soit en mode graphique, par exemple avec YaST. Dans le cas où votre nom d'utilisateur sur la machine locale et celui sur le système distant sont différents, vous pouvez spécifier un autre nom, par exemple ssh -l augustine sun ou ssh augustine@sun.

D'autre part, le programme ssh offre une possibilité connue avec rsh et consistant à exécuter des commandes sur un autre système. Dans l'exemple suivant, la commande uptime est exécutée sur la machine sun et un répertoire nommé tmp est créé. Le programme affiche sur le terminal local de la machine earth.

ssh soleil "uptime; mkdir tmp"
tux@soleil's password:
1:21pm  up  2:17,  9 users,  load average: 0.15, 0.04, 0.02

Dans cette commande, les guillemets sont requis afin de regrouper les deux instructions en une commande unique. C'est nécessaire pour permettre l'exécution de la seconde commande sur la machine sun.

Le programme scp vous permet de copier des fichiers sur une machine distante. scp constitue une alternative sécurisée et chiffrée au programme rcp. Ainsi, la commande scp MonCourrier.tex sun: copie le fichier MonCourrier.tex de la machine earth sur la machine sun. Dans le cas où le nom d'utilisateur sur earth est différent de celui sur sun, utilisez pour la commande scp la notation NomUtilisateur@NomMachine. L'option -l n'est pas disponible.

Après avoir saisi votre mot de passe, le programme scp commence à transférer les données en affichant l'avancement à l'aide d'une jauge formée d'astérisques et progressant de gauche à droite. Dans le même temps, la durée estimée restant jusqu'à la fin de la transmission (estimated time of arrival) est affichée sur la droite. Il est également possible d'inhiber l'affichage à l'aide de l'option -q.

La copie de fichiers individuels n'est pas la seule opération que scp permet d'effectuer. En effet, il est également possible de transférer récursivement des répertoires entiers : ainsi, la commande scp -r src/ sun:backup/ copie la totalité du répertoire src/, y compris les sous-répertoires présents sur la machine sun, dans le sous-répertoire backup/. Ce dernier est créé automatiquement s'il n'existe pas encore.

L'option -p permet à scp de conserver l'horodatage des fichiers. L'option -C permet de compresser les fichiers à transférer, ce qui, d'un côté, permet de réduire le volume de données à transférer, mais de l'autre, impose une charge supérieure au système.

On peut aussi utiliser le programme sftp pour transférer les données de façon sécurisée. sftp propose une session à l'intérieur de laquelle on peut utiliser plusieurs des commandes ftp bien connues. Par rapport à scp, le principal avantage est de pouvoir transférer des données lorsqu'on ne connaît pas le nom de fichier.

Pour pouvoir fonctionner, ssh et scp, les programmes clients du paquetage SSH ont besoin que le démon SSH qui est un serveur s'exécute en arrière-plan. Celui-ci attend les connexions sur le port TCP/IP numéro 22. La première fois qu'il est démarré, le démon génère trois paires de clés. Celles-ci comportent une partie privée et une partie publique (public). il s'agit donc d'une méthode à clé publique. Pour assurer la sécurité de l'application à l'aide de SSH, seul l'administrateur doit pouvoir voir les fichiers de la clé privée. Les privilèges correspondant sont définis par défaut de manière restrictive. Les clés privées sont utilisées en local uniquement par le démon SSH et ne doivent être communiquées à personne. En revanche, la partie publique de la clé (identifiable par l'extension de fichier .pub) peut être communiquée à vos correspondants et peut être lue par tous les utilisateurs.

Une connexion est créée par le client SSH. Le démon SSH en attente et le client SSH à l'origine de la demande échangent des données d'identification en vue de comparer la version du protocole et du logiciel et d'éviter une connexion sur un mauvais port. La réponse étant apportée par un processus fils du démon SSH initial, il est possible d'avoir plusieurs connexions SSH simultanément.

Afin d'assurer la communication entre le serveur SSH et le client SSH, le programme OpenSSH prend en charge les versions 1 et 2 du protocole SSH. Après avoir réinstallé SUSE Linux, c'est la version 2 actuelle du protocole qui est automatiquement utilisée. Si vous souhaitez continuer à utiliser SSH1 après une mise à jour, veuillez suivre les instructions données dans /usr/share/doc/packages/openssh/README.SuSE. Vous y trouverez également la marche à suivre pour passer d'un environnement SSH 1 à un environnement SSH 2 opérationnel.

Si vous utilisez le protocole SSH version 1, le serveur envoie sa clé d'hôte (en anglais, host key) publique ainsi qu'une clé de serveur (en anglais, server key) générée toutes les heures par le démon SSH. Grâce à ces deux clés, le client SSH chiffre une clé de session (en anglais, session key) et l'envoie au serveur SSH.Il communique par ailleurs au serveur la méthode de chiffrement choisie.

Le protocole SSH version 2 fonctionne sans la clé de serveur. Ce dispositif est remplacé par un algorithme de Diffie-Hellman destiné à l'échange des clés.

Il n'est pas possible de déduire les clés privées de l'hôte et du serveur, indispensables pour déchiffrer la clé de session, à partir des parties publiques de la clé. Ainsi, seul le démon SSH contacté est en mesure de déchiffrer la clé de session à l'aide de ses clés privées (voir man /usr/share/doc/packages/openssh/RFC.nroff). Cette phase préparatoire de la connexion peut être aisément tracée à l'aide de l'option de débogage -v du programme client SSH.

Par défaut, c'est la version 2 du protocole SSH qui est utilisée, même si le paramètre -1 permet d'imposer la version 1 du protocole SSH. En stockant après le premier contact toutes les clés publiques dans ~/.ssh/known_hosts, il est possible de contrer les attaques de type interception (man-in-the-middle). Les serveurs SSH tentant d'usurper le nom et l'adresse IP d'un autre sont démasqués avec un avertissement sans ambiguïté. Ils sont identifiés par leur clé d'hôte différente de ~/.ssh/known_hosts ou sont dans l'impossibilité de déchiffrer la clé de session convenue, faute de connaître la partie privée adéquate.

Il est recommandé d'archiver sur un support externe et en les protégeant comme il se doit les clés privées et publiques de /etc/ssh/. Vous pouvez ainsi constater d'éventuelles modifications apportées aux clés et récupérer les anciennes clés dans le cas où vous auriez à réinstaller votre système. Cette précaution épargnera aux utilisateurs l'inquiétude que peuvent causer des messages d'avertissement. Dans le cas où vous avez la certitude d'avoir à faire au bon serveur SSH en dépit de l'avertissement, la ligne existante correspondant au système doit être retirée du fichier ~/.ssh/known_hosts.

L'authentification proprement dite intervient à cet instant. Sous sa forme la plus simple, elle consiste à saisir un mot de passe, de manière analogue à la procédure illustrée dans les exemples précédents. L'objet de SSH était de mettre en place un logiciel sécurisé tout en restant simple à utiliser. Comme il visait à remplacer les programmes rsh et rlogin, SSH devait offrir une méthode d'authentification simple à utiliser au quotidien. Cet objectif est réalisé par SSH à l'aide d'une autre paire de clés générée ici par l'utilisateur. Le paquetage SSH offre pour cela l'utilitaire ssh-keygen. La paire de clés est générée après avoir saisi ssh-keygen -t rsa ou ssh-keygen -t dsa et vous devez indiquer un nom pour le fichier de base destiné à stocker les clés.

Validez la valeur par défaut et lorsque l'on vous demande une phrase de passe, donnez-en une. Même si le logiciel accepte une phrase de passe vide, nous conseillons de choisir un texte de 10 à 30 signes. Dans la mesure du possible, évitez d'utiliser des mots ou phrases courts et simples. Après la saisie, vous devez vérifier la première saisie en effectuant une seconde saisie. Vous devez ensuite indiquer l'emplacement de la clé privée et publique, en l'occurrence les fichiers id_rsa et id_rsa.pub.

Utilisez la commande ssh-keygen -p -t rsa ou ssh-keygen -p -t dsa pour modifier votre ancienne phrase de passe. Copiez la partie publique de la clé (dans notre exemple id_rsa.pub) sur la machine distante et enregistrez-la sous ~/.ssh/authorized_keys. Lors de la prochaine connexion, vous devrez saisir votre phrase de passe. Dans le cas contraire, vérifiez l'emplacement et le contenu des fichiers dont il vient d'être question.

À la longue, cette procédure s'avère plus lourde que celle consistant à saisir un mot de passe. Le paquetage SSH s'accompagne d'un utilitaire supplémentaire, ssh-agent, proposant des clés privées valables pour la durée d'une session X. Pour cela, le programme X est démarré comme processus fils de ssh-agent. La méthode la plus simple pour mettre cette fonctionnalité en place consiste à placer au début du fichier .xsession la variable usessh en fixant sa valeur à yes et à vous connecter à partir d'un gestionnaire de connexions tel que KDM ou XDM. Une autre possibilité est d'entrer ssh-agent startx.

Vous pouvez à présent utiliser ssh ou scp comme à l'accoutumée. Si vous avez partagé votre clé publique comme indiqué précédemment, vous devriez être dispensé de donner votre mot de passe. Lorsque vous vous éloignez de votre ordinateur, prenez toutefois la précaution de terminer votre session X ou de la verrouiller à l'aide d'un économiseur d'écran protégé par mot de passe, par exemple xlock.

Toutes les modifications importantes résultant de l'utilisation du protocole SSH version 2 sont également récapitulées dans le fichier /usr/share/doc/packages/openssh/README.SuSE.

Indépendamment des améliorations en matière de sécurité dont il vient d'être question, le programme ssh facilite également l'utilisation d'applications X distantes. Lorsque vous appelez ssh avec l'option -X, la variable DISPLAY est automatiquement définie sur le système distant et toutes les sorties X sont redirigées vers la machine source à travers la connexion ssh existante. Cette fonctionnalité pratique interdit dans le même temps les possibilités d'écoute qui existaient auparavant, lorsque l'on appelait à distance des applications X pour les afficher en local.

En définissant l'option -A, le mécanisme d'authentification de l'agent ssh-agent est repris sur la machine suivante. Vous pouvez ainsi passer d'une machine à l'autre sans être obligé de saisir de mot de passe. Ceci n'est toutefois possible que si vous avez préalablement copié et convenablement enregistré votre clé publique sur les machines cibles concernées.

Par précaution, les deux mécanismes sont désactivés par défaut, même s'ils peuvent être activés de manière permanente dans le fichier de configuration système /etc/ssh/ssh_config ou dans le fichier utilisateur ~/.ssh/config.

Le programme ssh peut également être utilisé afin de permettre des redirections de connexions TCP/IP. Exemple d'application : la redirection des ports SMTP et POP3 :

ssh -L 25:sun:25 earth

Dans cet exemple, toutes les connexions vers earth port 25 (SMTP) sont redirigées vers le port SMTP de sun via un canal chiffré. Cette possibilité est particulièrement utile pour les utilisateurs de serveurs SMTP dépourvus de fonctions SMTP-AUTH ou POP-before-SMTP. Ainsi, le courrier peut être transmis de n'importe quel endroit disposant d'une connexion réseau afin d'être acheminé par le serveur de messagerie domestique. De manière analogue, la commande suivante permet de rediriger toutes les requêtes POP3 (port 110) adressées à earth vers le port POP3 de sun :

ssh -L 110:sun:110 earth

Vous devez exécuter ces deux exemples en tant qu'utilisateur root, la connexion s'effectuant sur des ports locaux privilégiés. Lorsque la connexion SSH est établie, l'utilisateur envoie et reçoit les messages à partir de son compte habituel. L'hôte SMTP et POP3 doit être configuré à localhost. Vous trouverez des informations complémentaires dans les pages de manuels des différents programmes et dans les fichiers sous /usr/share/doc/packages/openssh.