Quelle est la différence entre le fichier authorized_keys et le fichier known_hosts pour SSH?

Question

J'apprends les bases du protocole SSH. Je suis confus entre le contenu des 2 fichiers suivants:

~/.ssh/authorized_keys: Contient une liste de clés publiques autorisées pour les serveurs. Lorsque le client se connecte à un serveur, le serveur authentifie le client en vérifiant sa clé publique signée stockée dans ce fichier
~/.ssh/known_hosts: Contient les clés d'hôte DSA des serveurs SSH accessibles par l'utilisateur. Ce fichier est très important pour garantir que le client SSH se connecte au bon serveur SSH.

Je ne suis pas sûr de ce que cela signifie. Veuillez aider.

Gilles &#39;SO- stop being evil&#39; · Accepted Answer

Le known_hosts fichier permet au client d'authentifier le serveur, pour vérifier qu'il ne se connecte pas à un imitateur. Le authorized_keys fichier permet au serveur d'authentifier l'utilisateur.

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

Au fait, known_hosts peut contenir tout type de clé publique pris en charge par l'implémentation SSH, pas seulement DSA (également RSA et ECDSA).

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 la 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_keys sur 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.

Scott Pack · Answer

Ces deux fichiers sont tous deux utilisés par SSH mais à des fins complètement différentes, ce qui pourrait facilement expliquer votre confusion.

Clés autorisées

Par défaut, SSH utilise des comptes d'utilisateurs et des mots de passe gérés par le système d'exploitation hôte. (Eh bien, effectivement géré par PAM mais cette distinction n'est probablement pas trop utile ici.) Ce que cela signifie, c'est que lorsque vous essayez de vous connecter à SSH avec le le nom d'utilisateur "bob" et un mot de passe que le programme du serveur SSH demandera au système d'exploitation "J'ai un gars nommé" bob "qui me dit que son mot de passe est" wonka ". Puis-je le laisser entrer? Si la réponse est oui, alors SSH vous permet de vous authentifier et vous continuez votre joyeux chemin.

En plus des mots de passe, SSH vous permettra également d'utiliser ce qu'on appelle cryptographie à clé publique pour vous identifier. L'algorithme de chiffrement spécifique peut varier, mais est généralement RSA ou DSA , ou plus récemment ECDSA . Dans tous les cas, lorsque vous configurez vos clés, utilisez le ssh-keygen programme, vous créez deux fichiers. Celui qui est votre clé privée et celui qui est votre clé publique. Les noms sont assez explicites. De par sa conception, la clé publique peut être éparpillée comme des graines de pissenlit dans le vent sans vous compromettre. La clé privée doit toujours être conservée dans la plus stricte confidentialité.

Donc, ce que vous faites est de placer votre clé publique dans le authorized_keys fichier. Ensuite, lorsque vous essayez de vous connecter à SSH avec le nom d'utilisateur "bob" et votre clé privée, il demandera au système d'exploitation "J'ai reçu ce nom de gars" bob ", peut-il être ici? Si la réponse est oui, SSH inspectera votre clé privée et vérifiera si la clé publique dans le authorized_keys le fichier est sa paire. Si les deux réponses sont oui, alors vous êtes autorisé à entrer.

Hôtes connus

Tout comme la façon dont le authorized_keys le fichier est utilisé pour authentifier les utilisateurs known_hosts le fichier est utilisé pour authentifier les serveurs. Chaque fois que SSH est configuré sur un nouveau serveur, il génère toujours une clé publique et privée pour le serveur, tout comme vous l'avez fait pour votre utilisateur. Chaque fois que vous vous connectez à un serveur SSH, il vous montre sa clé publique, ainsi qu'une preuve qu'il possède la clé privée correspondante. Si vous n'avez pas sa clé publique, votre ordinateur vous la demandera et l'ajoutera dans le known_hosts fichier. Si vous avez la clé et qu'elle correspond, vous vous connectez immédiatement. Si les touches ne correspondent pas, vous obtenez un gros avertissement désagréable. C'est là que les choses deviennent intéressantes. Les 3 situations dans lesquelles une incompatibilité de clé se produit généralement sont les suivantes:

La clé a changé sur le serveur. Cela peut être dû à la réinstallation de l'OS ou sur certains systèmes d'exploitation, la clé est recréée lors de la mise à jour de SSH.
Le nom d'hôte ou l'adresse IP auquel vous vous connectez appartenait à un autre serveur. Cela peut être une réaffectation d'adresse, DHCP , ou quelque chose de similaire.
Malicieux attaque d'homme au milie se produit. C'est la plus grande chose contre laquelle la vérification des clés tente de vous protéger.

Dans les deux cas, known_hosts et authorized_keys, le programme SSH utilise la cryptographie à clé publique pour identifier le client ou le serveur.

IAM_AL_X · Answer

À propos des fichiers sécurisés contenant des clés publiques

Pour vous aider à comprendre en quoi les "hôtes_connus" et "les clés autorisées" sont différents, voici un contexte expliquant comment ces fichiers s'intègrent dans "ssh". Il s'agit d'une simplification excessive; il y a beaucoup plus de capacités et de complications à "ssh" que celles mentionnées ici.

Les associations sont dans des sources fiables

Bien qu'il ait été dit que les valeurs des clés publiques "peuvent être éparpillées en toute sécurité comme des graines dans le vent", gardez à l'esprit que c'est le jardinier, et non la graine, qui décide des graines à établir dans le jardin. Bien qu'une clé publique ne soit pas secrète, une protection féroce est requise pour préserver l'association de confiance de la clé avec la chose que la clé authentifie. Les lieux chargés de faire cette association incluent les listes "connu_hôtes", "autorisé_les clés" et "autorité de certification".

Les sources fiables utilisées par "ssh"

Pour qu'une clé publique soit pertinente pour "ssh", la clé doit être enregistrée à l'avance et stockée dans le fichier sécurisé approprié. (Cette vérité générale a une exception importante, qui sera discutée plus loin.) Le serveur et le client ont chacun leur propre liste de clés publiques stockée en toute sécurité; une connexion ne réussira que si chaque côté est enregistré avec l'autre.

"known_hosts" réside sur le client
"authorized_keys" réside sur le serveur

Le fichier sécurisé du client est appelé "hôtes_connus" et le fichier sécurisé du serveur est appelé "clés_autorisées". Ces fichiers sont similaires en ce que chacun a du texte avec une clé publique par ligne, mais ils ont de subtiles différences de format et d'utilisation.

Les paires de clés sont utilisées pour l'authentification

Une paire de clés publique-privée est utilisée pour effectuer une "cryptographie asymétrique". Le programme "ssh" peut utiliser une cryptographie asymétrique pour l'authentification, où une entité doit répondre à un défi pour prouver son identité. Le défi est créé en encodant avec une clé, et répondu en décodant avec l'autre clé. (Notez que la cryptogrophie asymétrique est utilisée uniquement pendant la phase de connexion, puis "ssh" (TSL/SSL) passe à une autre forme de cryptage pour gérer le flux de données.)

Une paire de clés pour le serveur, une autre pour le client

Dans "ssh", les deux côtés (client et serveur) se méfient de l'autre; il s'agit d'une amélioration par rapport au prédécesseur de "ssh", qui était "telnet". Avec "telnet", le client devait fournir un mot de passe, mais le serveur n'a pas été vérifié. L'absence de vérification a permis à des attaques "d'homme du milieu" de se produire, avec des conséquences catastrophiques pour la sécurité. En revanche, dans le processus "ssh", le client ne remet aucune information jusqu'à ce que le serveur réponde à un défi.

Les étapes de l'authentification "ssh"

Avant de partager des informations de connexion, le client "ssh" élimine d'abord la possibilité d'une attaque de l'homme du milieu en mettant le serveur au défi de prouver "Êtes-vous vraiment qui je pense que vous êtes?" Pour relever ce défi, le client doit connaître la clé publique associée au serveur cible. Le client doit trouver le nom du serveur dans le fichier "known_hosts"; la clé publique associée est sur la même ligne, après le nom du serveur. L'association entre le nom du serveur et la clé publique doit être inviolée; par conséquent, les autorisations sur le fichier "known_hosts" doivent être de 600 - personne d'autre ne peut écrire (ni lire).

Une fois que le serveur s'est authentifié, il a une chance de défier le client. L'authentification impliquera l'une des clés publiques trouvées dans les "clés_autorisées". (Lorsqu'aucune de ces clés ne fonctionne, le processus "sshd" se replie sur l'authentification par mot de passe.)

Les formats de fichiers

Ainsi, pour "ssh", comme pour tout processus de connexion, il existe des listes d '"amis", et seuls ceux de la liste sont autorisés à tenter de passer un défi. Pour le client, le fichier "known_hosts" est une liste d'amis qui peuvent agir en tant que serveurs (hôtes); ceux-ci sont répertoriés par nom. Pour le serveur, la liste équivalente d'amis est le fichier "authorized_keys"; mais il n'y a aucun nom dans ce fichier, car les clés publiques elles-mêmes agissent comme des identifiants. (Le serveur ne se soucie pas d'où vient la connexion, mais seulement où il va. Le client tente d'accéder à un compte particulier, le nom du compte a été spécifié en tant que paramètre lorsque "ssh" a été invoqué. N'oubliez pas que les "touches_autorisées" "Le fichier est spécifique à ce compte, car le fichier se trouve dans le répertoire personnel de ce compte.)

Bien qu'il existe de nombreuses capacités qui peuvent être exprimées dans une entrée de configuration, l'utilisation de base la plus courante a les paramètres suivants. Notez que les paramètres sont séparés par des caractères d'espace.

Pour les "hôtes_connus":

{server-id} ssh-rsa {public-key-string} {comment}

Pour les "clés_autorisées":

ssh-rsa {public-key-string} {comment}

Notez que le jeton ssh-rsa indique que l'algorithme utilisé pour l'encodage est "rsa". D'autres algorithmes valides incluent "dsa" et "ecdsa". Par conséquent, un jeton différent peut remplacer le ssh-rsa montré ici.

Laissez "ssh" configurer automatiquement l'entrée "known_hosts"

Dans les deux cas, si la clé publique n'est pas trouvée dans un fichier sécurisé, le cryptage asymétrique ne se produit pas. Comme mentionné précédemment, il existe une exception à cette règle. Un utilisateur est autorisé à choisir sciemment de risquer la possibilité d'une attaque de l'homme du milieu en se connectant à un serveur qui n'est pas répertorié dans le fichier "known_hosts" de l'utilisateur. Le programme "ssh" avertit l'utilisateur, mais si l'utilisateur choisit d'aller de l'avant, le client "ssh" l'autorise "juste une fois". Pour vous assurer qu'il ne se produit qu'une seule fois, le processus "ssh" configure automatiquement le fichier "known_hosts" avec les informations requises en demandant au serveur la clé publique, puis en l'écrivant dans le fichier "known_hosts". Cette exception subvertit totalement la sécurité en permettant à l'adversaire de fournir l'association d'un nom de serveur avec une clé publique. Ce risque pour la sécurité est autorisé car il rend les choses beaucoup plus faciles pour tant de personnes. Bien sûr, la méthode correcte et sécurisée aurait été pour l'utilisateur d'insérer manuellement une ligne avec le nom du serveur et la clé publique dans le fichier "known_hosts" avant de tenter de se connecter au serveur. (Mais pour les situations à faible risque, le travail supplémentaire peut être inutile.)

Les relations un-à-plusieurs

Une entrée dans le fichier "known_hosts" du client a le nom d'un serveur et une clé publique qui est applicable à la machine serveur. Le serveur possède une seule clé privée qui est utilisée pour répondre à tous les défis, et l'entrée "known_hosts" du client doit avoir la clé publique correspondante. Par conséquent, tous les clients qui accèdent à un serveur particulier auront la même entrée de clé publique dans leur fichier "known_hosts". La relation 1: N est que la clé publique d'un serveur peut apparaître dans de nombreux fichiers "connus_hôtes" du client.

Une entrée dans le fichier "authorized_keys" identifie qu'un client amical est autorisé à accéder au compte. L'ami peut utiliser la même paire de clés publique-privée pour accéder à plusieurs serveurs différents. Cela permet à une seule paire de clés de s'authentifier auprès de tous les serveurs jamais contactés. Chacun des comptes de serveur ciblés aurait l'entrée de clé publique identique dans leurs fichiers "authorized_keys". La relation 1: N est que la clé publique d'un client peut apparaître dans les fichiers "authorized_keys" pour plusieurs comptes sur plusieurs serveurs.

Parfois, les utilisateurs qui travaillent à partir de plusieurs machines clientes répliqueront la même paire de clés; cela se fait généralement lorsqu'un utilisateur travaille sur un bureau et un ordinateur portable. Étant donné que les machines clientes s'authentifient avec des clés identiques, elles correspondront à la même entrée dans les "clés_autorisées" du serveur.

Emplacement des clés privées

Côté serveur, un processus système, ou démon, gère toutes les demandes de connexion "ssh" entrantes. Le démon est nommé "sshd". L'emplacement de la clé privée dépend de l'installation SSL, par exemple Apple la met à /System/Library/OpenSSL, mais après avoir installé votre propre version d'OpenSSL, l'emplacement sera /opt/local/etc/openssl.

Côté client, vous appelez "ssh" (ou "scp") lorsque vous en avez besoin. Votre ligne de commande comprendra divers paramètres, dont l'un peut éventuellement spécifier la clé privée à utiliser. Par défaut, la paire de clés côté client est souvent appelée $HOME/.ssh/id_rsa et $HOME/.ssh/id_rsa.pub.

Sommaire

L'essentiel, c'est que les "hôtes_connus" et les "clés_autorisées" contiennent des clés publiques, mais ...

known_hosts - le client vérifie si l'hôte est authentique
authorized_keys - l'hôte vérifie si la connexion client est autorisée