Authentification par clé SSH: hôtes_connus vs touches_autorisées

J'ai lu sur la configuration des clés ssh sous Linux et j'ai quelques questions. Corrige moi si je me trompe…

Disons que l'hôte tr-lgto veut se connecter à l'hôte tr-mdm à l'aide de ssh. Si nous voulons être sûrs qu'il s'agit du vrai tr-mdm, nous générons une paire de clés sur tr-mdm et nous ajoutons la clé publique à known_hostson 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_keyson 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 .sshdossier. Faut-il ajouter la clé publique à chacun des known_hostsfichiers?

Question 2 : J'ai trouvé que ssh-keyscan -t rsa tr-mdmretournera la clé publique de tr-mdm. Comment savoir à quel utilisateur appartient cette clé? De plus, la clé publique /root/.ssh/est différente 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.

Authentification du 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 à la cryptographie à clé publique ) au client qu'il connaît la 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_hostsfichier sur la machine client (il y a aussi 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_hostsmanuellement sur le client.

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é.

Authentification d'utilisateur

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).

• L'utilisateur peut présenter le mot de passe du compte auquel il tente de se connecter; le serveur vérifie ensuite que le mot de passe est correct.
• L'utilisateur peut présenter une clé publique et prouver qu'il possède la clé privée associée à cette clé publique. C'est exactement la même méthode que celle utilisée pour authentifier le serveur, mais maintenant l'utilisateur essaie de prouver son identité et le serveur les vérifie. La tentative de connexion est acceptée si l'utilisateur prouve qu'il connaît la clé privée et que la clé publique est dans la liste d'autorisation du compte ( ~/.ssh/authorized_keyssur le serveur).
• Un autre type de méthode consiste à déléguer une partie du travail d'authentification de l'utilisateur à la machine cliente. Cela se produit dans des environnements contrôlés tels que les entreprises, lorsque de nombreuses machines partagent les mêmes comptes. Le serveur authentifie la machine cliente par le même mécanisme que celui utilisé dans l'autre sens, puis s'appuie sur le client pour authentifier l'utilisateur.

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