J'ai lu sur la configuration des clés ssh sous Linux et j'ai quelques questions. Corrige moi si je me trompe…
Supposons que l'hôte tr-lgto souhaite se connecter à l'hôte tr-mdm à l'aide de ssh. Si nous voulons être sûrs que c'est le vrai tr-mdm, nous générons une paire de clés sur tr-mdm et nous ajoutons la clé publique à known_hosts
sur tr-lgto. Si tr-mdm veut vérifier qu'il s'agit bien du vrai tr-lgto, alors tr-lgto doit générer une paire de clés et ajouter la clé publique à authorized_keys
sur tr-mdm.
Question 1: Il n'y a pas de champ utilisateur dans le fichier known_hosts, juste des adresses IP et des noms d'hôte. tr-mdm peut avoir beaucoup d'utilisateurs, chacun avec son propre .ssh
dossier. Faut-il ajouter la clé publique à chacun des known_hosts
des dossiers?
Question 2: J'ai trouvé que ssh-keyscan -t rsa tr-mdm
renverra la clé publique de tr-mdm. Comment savoir à quel utilisateur appartient cette clé? De plus, la clé publique de /root/.ssh/
est différent de ce que renvoie cette commande. Comment se peut-il?
Vous mélangez l'authentification de la machine serveur à la machine cliente et l'authentification de l'utilisateur à la machine serveur.
L'une des premières choses qui se produit lorsque la connexion SSH est établie est que le serveur envoie sa clé publique au client et prouve (grâce à cryptographie à clé publique ) au client qu'il connaît le clé privée associée. Cela authentifie le serveur: si cette partie du protocole réussit, le client sait que le serveur est bien celui qu'il prétend être.
Le client peut vérifier que le serveur est connu, et non pas un serveur escroc essayant de se faire passer pour le bon. SSH ne fournit qu'un mécanisme simple pour vérifier la légitimité du serveur: il se souvient des serveurs auxquels vous êtes déjà connecté, dans le ~/.ssh/known_hosts
fichier sur la machine cliente (il existe également un fichier à l'échelle du système /etc/ssh/known_hosts
). La première fois que vous vous connectez à un serveur, vous devez vérifier par d'autres moyens que la clé publique présentée par le serveur est vraiment la clé publique du serveur auquel vous souhaitez vous connecter. Si vous disposez de la clé publique du serveur auquel vous vous connectez, vous pouvez l'ajouter à ~/.ssh/known_hosts
sur le client manuellement.
L'authentification du serveur doit être effectuée avant de lui envoyer des données confidentielles. En particulier, si l'authentification de l'utilisateur implique un mot de passe, le mot de passe ne doit pas être envoyé à un serveur non authentifié.
Le serveur ne permet à un utilisateur distant de se connecter que si cet utilisateur peut prouver qu'il a le droit d'accéder à ce compte. Selon la configuration du serveur et le choix de l'utilisateur, l'utilisateur peut présenter l'une de plusieurs formes d'informations d'identification (la liste ci-dessous n'est pas exhaustive).
~/.ssh/authorized_keys
sur le serveur).Mes amis m'ont donné la réponse. Par défaut, la clé identifie une machine et non un utilisateur. Les clés sont donc stockées dans/etc/ssh /. C'est pourquoi j'ai obtenu une clé différente de celle stockée dans /root/.ssh