Meilleure pratique: "clé ssh distincte par hôte et utilisateur" vs "une clé ssh pour tous les hôtes"
Est-il préférable de créer une clé SSH distincte pour chaque hôte et utilisateur ou simplement en utilisant le id_rsa clé pour tout hôte à authentifier? Pourrait-on id_rsa être une faute professionnelle pour les politiques de confidentialité/anonymat?
Mise à jour:
avoir une clé ssh pour tous les hôtes:
~/.ssh/id_rsa
~/.ssh/id_rsa.pub
par rapport aux clés ssh séparées:
~/.ssh/user1_Host1
~/.ssh/user1_Host1.pub
~/.ssh/user2_Host1
~/.ssh/user2_Host1.pub
~/.ssh/user3_Host2
~/.ssh/user3_Host2.pub
~/.ssh/user4_Host3
~/.ssh/user4_Host3.pub
... etc.
Une clé privée correspond à une seule "identité" pour un utilisateur donné, quoi que cela signifie pour vous. Si, pour vous, une "identité" est une seule personne, ou une seule personne sur une seule machine, ou peut-être une seule instance d'une application exécutée sur une seule machine. Le niveau de granularité dépend de vous.
En ce qui concerne la sécurité, vous ne compromettez pas votre clé de quelque manière que ce soit en l'utilisant pour vous connecter à une machine (comme vous le feriez en utilisant un mot de passe), donc avoir des clés séparées pour des destinations distinctes ne vous rend pas plus sûr du point de vue de l'authentification/sécurité.
Bien que le fait d'avoir la même clé autorisée pour plusieurs machines prouve que le même détenteur de clé a accès aux deux machines d'un point de vue médico-légal. En règle générale, ce n'est pas un problème, mais cela vaut la peine d'être souligné.
De plus, plus une seule clé est autorisée, plus cette clé devient précieuse. Si cette clé est compromise, davantage d'objectifs sont menacés.
De plus, plus la clé privée est stockée (par exemple, votre ordinateur de travail, votre ordinateur portable et votre stockage de sauvegarde, par exemple), plus il y a de places il y a pour un attaquant d'aller chercher une copie. Cela vaut donc la peine d'être considéré également.
Quant aux directives universellement applicables sur la façon d'exécuter votre sécurité: il n'y en a pas. Plus vous ajoutez de sécurité, plus vous abandonnez la commodité. Le seul conseil que je peux donner catégoriquement est le suivant: garder votre clé privée cryptée. La sécurité supplémentaire est assez importante.
Je pense que cette question peut être considérée sous deux angles différents: sécurité et commodité.
Lorsque nous créons une paire de clés SSH, il nous est demandé de fournir une phrase secrète pour ajouter une couche supplémentaire pour protéger la clé privée, comme suit:
$ ssh-keygen -t rsa -b 4096 -C 'With_OR_Without_Passwd'
Generating public/private rsa key pair.
Enter file in which to save the key (/Your/HomeDir/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Bien qu'il y ait une invite explicite demandant une phrase secrète, mais certaines (ou plusieurs) personnes se concentrent toujours plus sur les informations entre parenthèses: (vide pour aucune phrase secrète), et en suivant cette suggestion.
Combiner en utilisant ou non plusieurs paires de clés SSH et que ce soit ou pas entrer de mot de passe supplémentaire , nous avons au moins quatre façons de procéder. Et supposons que toutes les paires de clés et le fichier config sont stockés dans ~/.ssh/.
Maintenant, ne considérons pas sécurité d'abord.
Le tableau suivant donne un classement simple de la sécurité (un nombre plus élevé signifie plus de sécurité):
Security Ways to go
1 One SSH key-pair (NO passwd)
1 Multi SSH key-pairs (NO passwd)
2 One SSH key-pair (WITH passwd)
2 Multi SSH key-pairs (WITH passwd) (SAME passwd)
3 Multi SSH key-pairs (WITH passwd) (DIFF passwds)
Sans mot de passe , si notre système est envahi par quelqu'un, le disjoncteur peut obtenir toutes nos clés privées et notre configuration, ainsi que l'authentification des serveurs distants. Ainsi, dans cette situation, une paire de clés et plusieurs paires de clés sont identiques. Le moyen le plus sûr consiste à utiliser des mots de passe différents pour différentes paires de clés ssh.
Alors ne pensons pas à commodité.
Mais plus de paires de clés et plus de mots de passe rendent également notre vie moins pratique, le tableau suivant donne un classement simple sur la sécurité (un plus grand nombre signifie plus sécurisé):
Convenient Security Ways to go
5 1 One SSH key-pair (NO passwd)
4 2 One SSH key-pair (WITH passwd)
3 1 Multi SSH key-pairs (NO passwd)
2 2 Multi SSH key-pairs (WITH passwd) (SAME passwd)
1 3 Multi SSH key-pairs (WITH passwd) (DIFF passwds)
Donc, dans la situation générale, si nous devons échanger avec sécurité et commodité en même temps, nous pouvons multiplier les deux scores, et peut-être Une paire de clés SSH (AVEC passwd) est la bonne à choisir.
Vous n'avez besoin que d'une clé car la clé appartient à votre utilisateur.
Il n'y a aucun besoin (et aucune amélioration de la sécurité) d'avoir une clé par hôte.
Tant que votre clé privée reste privée, vous pouvez utiliser cette clé unique et l'utiliser pour vous authentifier auprès de plusieurs hôtes.
Quelle est la meilleure pratique: clé ssh séparée par hôte et utilisateur VS une clé ssh pour tous les hôtes?
Je ne sais pas si j'ai bien répondu à votre question, que voulez-vous dire par "clé"? faites-vous référence à la cryptographie asymétrique?
lorsque vous utilisez une cryptographie asymétrique, vous disposez d'une paire de clés privée et publique. La clé publique de chaque utilisateur est stockée sur le serveur ssh (Host). Cela permet d'authentifier l'utilisateur car pour chaque clé publique, il ne doit y avoir qu'une seule clé privée.
que voulez-vous dire par avoir une clé ssh pour tous les hôtes?
Le principal avantage des clés séparées est ce qui se passe dans le pire des cas: quelqu'un obtient votre clé privée.
- MÊME clé sur tous les hôtes: les méchants ont désormais accès à tout.
- DIFFÉRENTE clé sur chaque hôte: les méchants n'ont accès qu'à une seule chose.
Alors - le plus sûr? Clés uniques pour chaque hôte.
En règle générale, je suis d'accord avec les autres réponses - une seule clé par utilisateur est souvent le moyen le plus pratique de procéder. Ce n'est cependant pas une bonne solution pour tous.
Voici quelques considérations supplémentaires.
Si vous utilisez un agent SSH, plus de trois ou quatre clés deviennent problématiques, car lors de la connexion à un serveur, votre client SSH peut essayer l'une des clés stockées l'une après l'autre. Cela peut entraîner plusieurs échecs de connexion côté serveur, et vous pouvez en fait constater que votre compte est verrouillé avant que SSH ne tente même la bonne clé. Cet aspect favorise l'approche à une clé par utilisateur.
Si vous servez plusieurs entités indépendantes (comme un consultant au service de plusieurs clients), envisagez une clé SSH distincte pour chaque client. Il n'est pas rare que lorsque la relation se termine, le client peut exiger la remise de tous les mots de passe et clés SSH. Parfois, expliquer pourquoi ce n'est pas une bonne idée fonctionne, mais si le client obtient quelque chose comme une ordonnance du tribunal, vous pouvez avoir un problème.
Si votre clé privée SSH est compromise, vous devrez peut-être la modifier sur de nombreux systèmes. Avez-vous même rappelez-vous tous les systèmes que vous avez jamais, au cours des dix dernières années, mis en place avec cette clé SSH? Vous souviendrez-vous de supprimer votre clé SSH compromise de Github? Ou du routeur dans un placard du bureau, un couple déclare que vous gérez à distance? Qu'en est-il des systèmes que vous ne pouvez plus toucher parce que vous ne travaillez plus pour ce client particulier?
En fin de compte, il s'agit de comprendre les implications des deux approches et de les mettre en balance avec les préoccupations particulières de votre situation.
Cela peut arriver un peu tard, mais je pense que cela mérite d'être mentionné: Du point de vue de la sécurité et de la commodité, lors de la gestion des utilisateurs humains, il est souhaitable d'avoir une clé par utilisateur.
Les avantages surviennent lorsque vous devez révoquer l'accès à un seul utilisateur.
Disons que vous utilisez une clé pour tous les utilisateurs et sans mot de passe (ou avec le même mot de passe). Vous pouvez désactiver l'utilisateur sur le serveur (le "compte"), mais tous les besoins humains sont l'utilisateur et la clé pour y accéder. Il/elle a déjà la clé car c'est un fichier, vous ne pouvez pas contrôler cela, puis il a juste besoin d'un nom d'utilisateur (peut-être que l'utilisateur (les comptes) sont créés avec un algorithme standard (par exemple, première lettre de nom + nom de famille)) pour gagner l'accès en tant qu'autre utilisateur. Ensuite, pour des raisons de sécurité, vous devrez créer une nouvelle paire de clés (et la remettre aux utilisateurs) et désactiver l'ancienne paire de clés.
C'est beaucoup plus simple si vous avez une clé par utilisateur, car vous désactivez simplement l'utilisateur (et la clé si vous le souhaitez).
Lorsque vous gérez des systèmes ou des serveurs qui traitent des données sensibles, où le pool d'utilisateurs est variable (et ce sera certainement le cas, ce qui varie est la vitesse de rotation), cela devient une bonne pratique en termes de sécurité et de commodité.
Depuis que la question a été posée, le paysage a considérablement changé. Aujourd'hui, deux points favorisent une seule clé SSH pour tous les hôtes.
- Les clés matérielles deviennent de plus en plus populaires. Au moins la marque sans doute la plus populaire, Yubikey, ne prend en charge qu'une seule clé SSH.
- Si vous utilisez un serveur LDAP pour l'authentification, vous pouvez ajouter une schama LDAP pour stocker une clé publique SSH dans LDAP, au lieu de l'ajouter à chaque hôte individuellement. Certaines autres solutions IDM peuvent également offrir des fonctionnalités similaires.
Bien sûr, cela n'invalide pas les autres considérations mentionnées dans les réponses précédentes.