Le fichier known_hosts permet au client dauthentifier le serveur, pour vérifier quil ne se connecte pas à un impersonator. Le fichier authorized_keys permet le serveur authentifie lutilisateur.

Authentification du serveur

Une des premières choses qui se produit lors de létablissement de la connexion SSH est que le serveur envoie sa clé publique au client, et prouve (grâce à la cryptographie à clé publique ) au client quil connaît la clé privée associée. Cela authentifie le serveur: si cette partie du protocole réussit, le le client sait que le serveur est celui quil prétend être.

Le client peut vérifier que le serveur est connu, et non un serveur non autorisé essayant de faire passer pour la bonne. SSH ne fournit quun mécanisme simple pour vérifier la légitimité du serveur: il se souvient des serveurs auxquels vous êtes déjà connecté, dans le fichier ~/.ssh/known_hosts sur la machine client (il y a aussi un système -wide file /etc/ssh/known_hosts). La première fois que vous vous connectez à un serveur, vous devez vérifier par un autre moyen que la clé publique présentée par le serveur est bien la clé publique du serveur auquel vous vouliez vous connecter. Si vous disposez de la clé publique du serveur auquel vous êtes sur le point de vous connecter, vous pouvez lajouter manuellement à ~/.ssh/known_hosts sur le client.

À propos, known_hosts peut contenir tout type de clé publique pris en charge par limplémentation SSH, pas seulement DSA (également RSA et ECDSA).

Authentification du serveur doit être effectué avant de lui envoyer des données confidentielles. En particulier, si lauthentification de lutilisateur implique un mot de passe, le mot de passe ne doit pas être envoyé à un serveur non authentifié.

Authentification de lutilisateur

Le serveur ne permet à un utilisateur distant de se connecter que si cet utilisateur peuvent prouver quils ont le droit daccéder à ce compte. En fonction de la configuration du serveur et du choix de l’utilisateur, l’utilisateur peut présenter l’une des nombreuses formes d’identification (la liste ci-dessous n’est pas exhaustive).

• L’utilisateur peut présenter le mot de passe pour le compte auquel il tente de se connecter; le serveur vérifie alors que le mot de passe est correct.
• Lutilisateur peut présenter une clé publique et prouver quil possède la clé privée associée à cette clé publique. Cest exactement la même méthode que celle utilisée pour authentifier le serveur, mais maintenant lutilisateur tente de prouver son identité et le serveur la vérifie. La tentative de connexion est acceptée si lutilisateur prouve quil connaît la clé privée et que la clé publique est dans la liste dautorisation du compte (~/.ssh/authorized_keys sur le serveur).
• Un autre type de méthode consiste à déléguer une partie du travail dauthentification de lutilisateur à 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 client par le même mécanisme utilisé dans lautre sens, puis sappuie sur le client pour authentifier lutilisateur.

Commentaires

• merci cest très utile. il est juste de dire que le fichier known_hosts est maintenu sur le client alors que le fichier autorisé_key est maintenu sur le serveur
• @Ankit Oui, cest le cas.
• Jai les deux fichiers sur le serveur et ssh pour le tester. Mais les 2 fichiers ont un contenu différent. Donc les clés sont différentes dans ces fichiers?
• @Timo Les clés sont complètement non ravi. Lune est la clé dune machine, lautre est la clé dun utilisateur.
• @Gilles Donc une fois que lentrée pour un serveur ‘ la clé publique est ajoutée au fichier known_hosts de la machine du client ‘, toute session ssh ultérieure entre les deux ne ‘ t demander au serveur de prouver quil possède la bonne clé privée?

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 dutilisateurs et des mots de passe gérés par le système dexploitation hôte. (En fait, géré par PAM mais cette distinction nest probablement pas trop utile ici.) Cela signifie que lorsque vous essayez de vous connecter à SSH avec le nom dutilisateur « bob » et un mot de passe que le programme du serveur SSH demandera au système dexploitation  » Jai trouvé ce type 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 chemin.

En plus des mots de passe SSH vous permettra également dutiliser ce que lon appelle cryptographie à clé publique pour vous identifier. Lalgorithme de chiffrement spécifique peut varier, mais il 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 , vous créez deux fichiers. Un qui est votre clé privée et lautre qui est votre clé publique. Les noms sont assez propres -explicatif. 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 public saisissez le fichier authorized_keys. Ensuite, lorsque vous essayez de vous connecter à SSH avec le nom dutilisateur « bob » et votre clé privée, il demandera au système dexploitation  » Jai ce nom de type « bob », peut être ici?  » Si la réponse est oui alors SSH inspectera votre clé privée et vérifiera si la clé publique dans le fichier authorized_keys est sa paire. Si les deux réponses sont oui, vous êtes autorisé à entrer.

Hôtes connus

Tout comme la façon dont le fichier authorized_keys est utilisé pour authentifier les utilisateurs le fichier known_hosts 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, comme vous lavez fait pour votre utilisateur. Chaque fois que vous vous connectez à un serveur SSH, il vous montre sa clé publique, avec une preuve quil possède la clé privée correspondante. Si vous ne disposez pas de sa clé publique, votre ordinateur la demandera et lajoutera dans le fichier known_hosts. Si vous avez la clé et quelle correspond, vous vous connectez immédiatement. Si les clés ne correspondent pas, vous recevez un gros avertissement. Cest là que les choses deviennent intéressantes. Les 3 situations dans lesquelles une incompatibilité de clé se produit généralement sont:

1. La clé a changé sur le serveur. Cela peut être dû à la réinstallation du OS ou sur certains systèmes dexploitation, la clé est recréée lors de la mise à jour de SSH.
2. Le nom dhôte ou ladresse IP que vous connectez pour appartenir à un autre serveur. Il peut sagir dune réaffectation dadresse, DHCP ou quelque chose de similaire.
3. Malicieux man- une attaque au milieu est en cours. Cest la chose la plus importante 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 soit le client, soit le serveur.

Commentaires

•  » Chaque fois que vous vous connectez à un serveur SSH, il présente sa clé privée afin de prouver son identité.  » Jespère certainement que non! Je suppose que vous vouliez dire sa clé publique . Si un serveur me présentait, le client, avec sa clé privée – il (A) ne fonctionnerait pas ‘ pour que je l’authentifie et (B) est une indication que le serveur est ainsi mal configuré que je devrais arrêter de faire affaire avec lui immédiatement. Les clés privées ne doivent être accessibles sur la machine dorigine que par des utilisateurs désignés. Cest ‘ que cest un peu le point. 😉
• Cette réponse ma aidé plus que celle acceptée (:
• Si je ssh vers un serveur local (IP local), puis plus tard depuis le même ordinateur mais maintenant à distance se connecter au même serveur (IP publique), cela déclenchera-t-il des clés incompatibles? Comment pouvez-vous atténuer cela?

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

Pour vous aider à comprendre en quoi « known_hosts » et « allowed_keys » sont différents, voici un contexte expliquant comment ces fichiers sintègrent dans « ssh ». «ssh» comporte beaucoup plus de capacités et de complications que celles mentionnées ici.

Les associations sont dans des sources fiables

Bien quil ait été dit que les valeurs de clé publique « peuvent être éparpillées en toute sécurité comme des graines dans le vent », gardez à lesprit que cest le le jardinier, et non la gousse, qui décide quelles graines sétabliront dans le jardin. Bien quune clé publique ne soit pas secrète, une protection féroce est nécessaire pour préserver lassociation de confiance de la clé avec la chose que la clé authentifie. Les lieux chargé de faire en sorte que cette association inclue les listes « known_hosts », « allowed_keys » et « Certificate Authority ».

Les sources fiables utilisées par « ssh »

Pour quune clé publique soit pertinente pour «ssh», la clé doit être enregistrée à lavance et stockée dans le fichier sécurisé approprié (cette vérité générale comporte une exception importante, qui sera discutée plus tard.) Le serveur et le client ont chacun leur propre, stocké en toute sécurité liste de clés publiques; une connexion ne réussira que si chaque côté est enregistré avec lautre.

• « known_hosts » réside sur le clie nt
• « allowed_keys » réside sur le serveur

Le fichier sécurisé du client est appelé « known_hosts » et le fichier sécurisé du serveur est appelé « allowed_keys » . Ces fichiers sont similaires en ce sens que chacun contient du texte avec une clé publique par ligne, mais ils présentent des différences subtiles de format et dutilisation.

Les paires de clés sont utilisées pour lauthentification

Un public -les paires de clés privées sont utilisées pour effectuer une «cryptographie asymétrique». Le programme « ssh » peut utiliser la cryptographie asymétrique pour lauthentification, 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épond en décodant avec lautre clé. (Notez que la cryptogrophie asymétrique nest utilisée que 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 lautre; il sagit dune 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 na pas été vérifié. Labsence de contrôle a permis à des attaques de type «man-in-the-middle» de se produire, avec des conséquences catastrophiques pour la sécurité. En revanche, dans le processus « ssh », le client ne cède aucune information jusquà ce que le serveur réponde dabord à un défi.

Les étapes de lauthentification « ssh »

Avant de partager des informations de connexion, le client « ssh » élimine dabord lopportunité dune attaque de type « man-in-the-middle » en demandant au serveur de prouver « Es-tu vraiment qui je pense que tu es? » 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. Lassociation entre le nom du serveur et la clé publique doit rester inviolable; par conséquent, les autorisations sur le fichier « known_hosts » doit être 600 – personne dautre ne peut écrire (ni lire).

Une fois que le serveur sest authentifié, il a une chance de contester le client. Lauthentification impliquera lun des publics- clés trouvées dans les « clés_autorisées ». (Quand aucune de ces clés ne fonctionne, le processus « sshd » se rabat sur lauthentification par mot de passe.)

Les formats de fichiers

Donc pour  » ssh « , comme pour tout processus de connexion, il existe des listes » damis « , et seuls ceux de la liste sont autorisés à tenter de relever un défi. Pour le client, le fichier » known_hosts « est une liste damis qui peuvent agir en tant que serveurs (hôtes); ceux-ci sont listés par nom. Pour le serveur, la liste équivalente damis est le fichier « authorized_keys »; mais il ny a pas de noms dans ce fichier, puisque le publi Les clés c agissent elles-mêmes comme des identifiants. (Le serveur ne se soucie pas de la provenance de la connexion, mais uniquement de sa destination. Le client tente daccéder à un compte particulier, le nom du compte a été spécifié en tant que paramètre lorsque « ssh » a été appelé. Noubliez pas que le Le fichier « authorized_keys » est spécifique à ce compte, car le fichier se trouve dans le répertoire personnel de ce compte.)

Bien quil existe de nombreuses fonctionnalités qui peuvent être exprimées dans une entrée de configuration, lutilisation de base la plus courante a les paramètres suivants. Notez que les paramètres sont séparés par des espaces.

Pour « known_hosts »:

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

Pour « allowed_keys »:

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

Notez que le jeton ssh-rsa indique que lalgorithme utilisé pour le codage est « rsa ». Autres algorithmes valides inclure « dsa » et « ecdsa ». Par conséquent, un jeton différent peut remplacer le ssh-rsa affiché ici.

Laissez « ssh » configurer automatiquement le Entrée « known_hosts »

Dans les deux cas, si e La clé publique nest pas trouvée dans un fichier sécurisé, alors 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é dune attaque de type « man-in-the-middle » en se connectant à un serveur qui nest pas répertorié dans le fichier « known_hosts » de lutilisateur. Le programme « ssh » avertit lutilisateur, mais si lutilisateur choisit daller de lavant, le client « ssh » lautorise « une seule fois ». Pour sassurer que cela se produit une seule fois, le processus « ssh » configure automatiquement le fichier « known_hosts » avec les informations requises en demandant au serveur le clé publique, puis lécriture dans le fichier « known_hosts ». Cette exception sape totalement la sécurité en permettant à ladversaire de fournir lassociation dun nom de serveur avec une clé publique. Ce risque de sécurité est autorisé car il rend les choses tellement importantes Bien sûr, la méthode correcte et sécurisée aurait été pour lutilisateur dinsé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 des hôtes connus du client a le nom dun serveur et une clé publique applicable à la machine serveur. Le serveur a une seule clé privée qui est utilisée pour répondre à tous les défis, et lentrée du client « known_hosts » doit avoir la clé publique correspondante. Par conséquent, tous les clients qui accèdent à un serveur particulier auront la même clé publique dans leur fichier « known_hosts ». La relation 1: N est que la clé publique dun serveur peut apparaître dans les fichiers « known_hosts » de nombreux clients.

Une entrée dans le fichier « allowed_keys » identifie quun client convivial est autorisé à accéder au compte. Lami 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 sauthentifier auprès de tous les serveurs contactés. Chacun des comptes de serveurs ciblés auraient la même entrée de clé publique dans leurs fichiers « authorized_keys ». La relation 1: N est que la clé publique dun client peut apparaître dans les fichiers « allowed_keys » pour plusieurs comptes sur plusieurs serveurs.

Parfois, les utilisateurs qui travaillent à partir de plusieurs ordinateurs clients répliquent la même paire de clés; généralement, cela est fait lorsquun utilisateur travaille sur un bureau et un ordinateur portable. Parce que les machines clientes sauthentifient 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

Pour le côté serveur, un processus système , ou démon, gère toutes les demandes de connexion entrantes « ssh ». Le démon est nommé « sshd ». Lemplacement de la clé privée dépend de linstallation SSL, par exemple Apple la place sur /System/Library/OpenSSL, mais après avoir installé votre propre version dOpenSSL, lemplacement sera /opt/local/etc/openssl.

Pour le côté client, vous invoquez « ssh » (ou « scp » ) lorsque vous en avez besoin. Votre ligne de commande comprendra divers paramètres, dont lun 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.

Résumé

En fin de compte, « known_hosts » et « allowed_keys » contiennent des clés publiques, mais …

• known_hosts – le client vérifie si lhôte est authentique
• authorized_keys – lhôte vérifie si la connexion client est autorisée

Commentaires

• Les clients SSH ne font généralement pas ‘ t avoir des clés. Les clés publiques répertoriées dans authorized_keys identifient les utilisateurs, pas les machines.
• Merci. Ceci est une explication très claire et facilement compréhensible des relations entre les fichiers et les clés.

Pas vrai du tout.

Le fichier known_hosts contient lempreinte digitale de lhôte. Ce nest pas la clé publique ou privée de lhôte distant.

Elle est générée à partir de sa clé – mais ce nest absolument PAS la clé elle-même.

Si vous utilisez un SFTP à une adresse qui peut se résoudre à plusieurs hôtes (variables) (charge équilibrée, etc.), vous devez ajouter les empreintes digitales de tous les points de terminaison possibles, ou cela fonctionnera initialement puis échouera lorsquil sera acheminé vers le deuxième hôte (ou suivant).

Commentaires

• erm regardez votre fichier known_hosts et comparez-le à une empreinte de lhôte lorsque vous vous connectez …. Cela devrait clarifier un peu la situation. De plus, votre exemple serait exactement le même, quil sagisse dempreintes digitales ou de clés publiques dans le fichier known_hosts.