La procédure suivante définit un système de clé publique où la clé publique du client est utilisée pour l'authentification sur le serveur. L'utilisateur doit également créer une paire de clés publiques ou privées.
Dans cette procédure, les termes client et hôte local désignent la machine sur laquelle un utilisateur saisit la commande ssh. Les termes serveur et hôte distant font tous deux référence au système que le client tente d'atteindre.
Avant de commencer
Vous devez prendre le rôle root. Pour plus d'informations, reportez-vous à la section A l’aide de vos droits administratifs attribués du manuel Sécurisation des utilisateurs et des processus dans Oracle Solaris 11.2 .
Dans le fichier de configuration du client, /etc/ssh/ssh_config, tapez l'entrée suivante :
HostbasedAuthentication yes
Pour connaître la syntaxe du fichier de configuration, reportez-vous à la page de manuel ssh_config(4).
Dans le fichier de configuration du serveur, /etc/ssh/sshd_config, saisissez la même entrée :
HostbasedAuthentication yes
Pour connaître la syntaxe du fichier, reportez-vous à la page de manuel sshd_config(4).
Pour plus d'informations, reportez-vous à la section FILES de la page de manuel sshd(1M).
client-host
client-host
Définissez IgnoreRhosts sur no dans le fichier /etc/ssh/sshd_config.
## sshd_config IgnoreRhosts no
## sshd_config IgnoreUserKnownHosts no
Pour des instructions d'utilisation, reportez-vous à la section Génération d'une paire clé publique/clé privée à utiliser avec le shell sécurisé.
Les clés d'hôte sont stockées dans le répertoire /etc/ssh. Ces clés sont généralement générées par le démon sshd à la première initialisation.
Sur le client, saisissez la commande suivante sur une seule ligne, sans barre oblique inverse.
# cat /etc/ssh/ssh_host_dsa_key.pub | ssh RemoteHost \ 'cat >> /etc/ssh/ssh_known_hosts && echo "Host key copied"'
Client and server could not agree on a key exchange algorithm: client "diffie-hellman-group-exchange-sha256,diffie-hellman-group- exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1", server "gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==". Make sure host keys are present and accessible by the server process. See sshd_config(4) description of "HostKey" option.
Lorsque le fichier est copié, le message "Host key copied" (Clé d'hôte copiée) s'affiche.
Chaque ligne du fichier /etc/ssh/ssh_known_hosts se compose de champs séparés par des espaces :
hostnames algorithm-name publickey comment
## /etc/ssh/ssh_known_hosts File RemoteHost <copied entry>
Dans l'exemple ci-dessous, chaque hôte est configuré en tant que serveur et en tant que client. Un utilisateur de l'un ou l'autre hôte peut lancer une connexion ssh à l'autre hôte. La configuration suivante convertit chaque hôte en serveur et client :
Sur chaque hôte, les fichiers de configuration Shell sécurisé contiennent les entrées suivantes :
## /etc/ssh/ssh_config HostBasedAuthentication yes # ## /etc/ssh/sshd_config HostBasedAuthentication yes IgnoreRhosts no
Sur chaque hôte, le fichier shosts.equiv contient une entrée pour l'autre hôte :
## /etc/ssh/shosts.equiv on machine2 machine1
## /etc/ssh/shosts.equiv on machine1 machine2
La clé publique pour chaque hôte est contenue dans le fichier /etc/ssh/ssh_known_hosts sur l'autre hôte :
## /etc/ssh/ssh_known_hosts on machine2 … machine1
## /etc/ssh/ssh_known_hosts on machine1 … machine2
Les utilisateurs possèdent un compte sur les deux hôtes. Par exemple, les informations suivantes s'afficheraient pour l'utilisateur John Doe :
## /etc/passwd on machine1 jdoe:x:3111:10:J Doe:/home/jdoe:/bin/sh
## /etc/passwd on machine2 jdoe:x:3111:10:J Doe:/home/jdoe:/bin/sh