Authentification par clé SSH: hôtes_connus vs touches

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?

ssh security openssh key-authentication damluar
la source

Question similaire sur la sécurité de l'information : quelle est la différence entre le fichier authorisé_clé et le fichier connu_hôte pour SSH?

Gilles 'SO- arrête d'être méchant'

J'ai ajouté un contexte d'arrière-plan pour 'ssh' dans une réponse "À propos des fichiers sécurisés contenant des clés publiques" à la question mentionnée par @Gilles: < security.stackexchange.com/questions/20706/… >

IAM_AL_X

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.

Gilles 'SO- arrête d'être méchant'
la source

Bonne réponse Gilles, mais ma question est que n'importe quel serveur peut envoyer une clé publique aléatoire et prouver qu'il a la clé publique associée. Comment cela prouve-t-il que le serveur est authentique?

Alex

@spartacus Je pense que vous vouliez dire "et prouver qu'il possède la clé privée associée", non? L'idée est que le client envoie une valeur générée aléatoirement (un défi ) au serveur, et le serveur effectue un calcul basé sur la clé privée qui dépend du défi (de sorte que le serveur ne peut pas effectuer le calcul jusqu'à ce qu'il le reçoive). défi) et cela ne peut être fait qu'avec la connaissance de la clé privée.

Gilles 'SO- arrête d'être méchant'

Je pense qu'Alex fait référence à la première fois que le client se connecte au serveur. Je pense que le client fera confiance au serveur cette première fois. Le serveur enverra alors sa clé publique et le client pourra authentifier le serveur pour les connexions suivantes.

synack

@synack Ah, la première fois? C'est plutôt le client que l'utilisateur prend la décision («Êtes-vous sûr de vouloir continuer à vous connecter (oui / non)?»). Le serveur ne prouve rien à ce stade.

Gilles 'SO- arrête d'être méchant'

vous avez raison, c'est l'utilisateur qui prend la décision.

synack

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

Réponses:

Authentification du serveur

Authentification d'utilisateur