Le known_hosts permet au client d'authentifier le serveur, pour vérifier qu'il ne se connecte pas à un imitateur. Le authorized_keys permet au serveur d'authentifier l'utilisateur.
Authentification du serveur
Une des premières choses qui se passe 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 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 celui qu'il prétend être.
Le client peut vérifier que le serveur est connu, et non un serveur malveillant 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 vous êtes déjà connecté, dans le ~/.ssh/known_hosts fichier sur la machine cliente (il existe également un fichier système /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 avez la clé publique du serveur auquel vous allez vous connecter, vous pouvez l'ajouter à ~/.ssh/known_hosts sur le client manuellement.
Au fait, known_hosts peut contenir n'importe quel 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 de l'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 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 alors 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 qui est 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_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.
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, en fait géré par PAM mais cette distinction n'est probablement pas très utile ici.) Cela signifie que lorsque vous essayez de vous connecter à SSH avec le nom d'utilisateur 'bob' et un mot de passe, le programme serveur SSH demandera au système d'exploitation "I J'ai un 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 petit bonhomme de chemin.
En plus des mots de passe, SSH vous permettra également d'utiliser ce qu'on appelle la cryptographie à clé publique pour vous identifier. L'algorithme de chiffrement spécifique peut varier, mais il s'agit généralement de RSA ou de DSA, ou plus récemment d'ECDSA. Dans tous les cas lors de la configuration de vos clés, en utilisant le ssh-keygen programme, vous créez deux fichiers. Une qui est votre clé privée et une qui est votre clé publique. Les noms sont assez explicites. De par sa conception, la clé publique peut être semé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 dossier. 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 ce type qui s'appelle 'bob', peut-il être ici?" Si la réponse est oui, alors SSH inspectera votre clé privée et vérifiera si la clé publique dans le authorized_keys file est sa paire. Si les deux réponses sont oui, alors vous êtes autorisé à entrer.
Hôtes connus
Tout comme le authorized_keys le fichier est utilisé pour authentifier les utilisateurs le 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, alors votre ordinateur la demandera et l'ajoutera dans le known_hosts dossier. Si vous avez la clé et qu'elle correspond, vous vous connectez immédiatement. Si les clés 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 :
- La clé a changé sur le serveur. Cela peut provenir de la réinstallation du système d'exploitation 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. Il peut s'agir d'une réattribution d'adresse, de DHCP ou de quelque chose de similaire.
- Une attaque malveillante de type "man-in-the-middle" est en cours. C'est la chose la plus importante dont la vérification des clés essaie de vous protéger.
Dans les deux cas, known_hosts et authorized_keys , le programme SSH utilise la cryptographie à clé publique afin d'identifier le client ou le serveur.
À propos des fichiers sécurisés contenant des clés publiques
Pour vous aider à comprendre en quoi "known_hosts" et "authorized_keys" sont différents, voici un contexte expliquant comment ces fichiers s'intègrent dans "ssh". C'est une simplification excessive; il y a beaucoup plus de fonctionnalités et de complications pour "ssh" que celles mentionnées ici.
Les associations sont dans des sources fiables
Bien qu'il ait été dit que les valeurs de clé publique "peuvent être dispersé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 quelles graines s'établir dans le jardin. Bien qu'une clé publique ne soit pas secrète, une protection féroce est nécessaire pour préserver l'association de confiance de la clé avec la chose que la clé authentifie. Les endroits confiés pour faire cette association incluent les listes "known_hosts", "authorized_keys" et "Certificate Authority".
Les sources de confiance 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 tard.) 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 partie est enregistrée auprès de l'autre.
- "known_hosts" réside sur le client
- "authorized_keys" réside sur le serveur
Le fichier sécurisé du client s'appelle "known_hosts" et le fichier sécurisé du serveur s'appelle "authorized_keys". Ces fichiers sont similaires en ce sens que chacun contient du texte avec une clé publique par ligne, mais ils présentent 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 la 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 cryptographie asymétrique n'est 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 l'un 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'était pas contrôlé. L'absence de contrôle a permis à des attaques "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 communique aucune information tant que le serveur n'a pas répondu à un défi.
Les étapes de l'authentification "ssh"
Avant de partager toute information de connexion, le client "ssh" élimine d'abord la possibilité d'une attaque de type "man-in-the-middle" en défiant le serveur 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 maintenue 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 la possibilité de défier le client. L'authentification impliquera l'une des clés publiques trouvées dans les "authorized_keys". (Lorsqu'aucune de ces clés ne fonctionne, le processus "sshd" se rabat 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 qui figurent sur la liste sont autorisés à tenter de relever 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 d'amis équivalente est le fichier "authorized_keys" ; mais il n'y a pas de noms dans ce fichier, puisque 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ù elle 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é appelé. N'oubliez pas que le "authorized_keys " 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 fonctionnalités pouvant être exprimées dans une entrée de configuration, l'utilisation de base la plus courante comporte 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 "authorized_keys":
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 ne se trouve pas dans un fichier sécurisé, le chiffrement 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 man-in-the-middle 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 pour cette fois". Pour garantir que cela ne se produise 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 de 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é que l'utilisateur insère 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 s'applique à la machine serveur. Le serveur a 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 les fichiers "known_hosts" de nombreux clients.
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 contactés. Chacun des comptes de serveur ciblés aurait la même entrée de clé publique 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; généralement, cela se fait lorsqu'un utilisateur travaille sur un ordinateur de 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 "authorized_keys" 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 "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 place à /System/Library/OpenSSL , mais après avoir installé votre propre version d'OpenSSL, l'emplacement 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 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 .
Résumé
L'essentiel est que "known_hosts" et "authorized_keys" 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 du client est autorisée