Recevoir une clé privée de l'administrateur du serveur: ok ou pas?

Je dois accéder à un serveur SFTP distant. L'administrateur a créé un utilisateur pour moi et a généré une paire de clés publique / privée pour moi. Ensuite, il m'a envoyé en toute sécurité le fichier de clé privée, que j'utilise pour l'authentification. Je crois que ce n'est pas bon, je devrais être celui qui génère la paire de clés et lui donne la clé publique. Mais je ne peux penser à aucune bonne raison pour laquelle cela est mauvais, si j'utilise cette clé uniquement pour me connecter à ce serveur, pas d'autres serveurs. Y a-t-il de telles raisons?

authentication ssh-keys private-key

— matthiash
source

Mauvaise hygiène de sécurité, pour un. L'administrateur du serveur devrait être mieux informé et ne devrait pas "former" les utilisateurs à s'attendre à obtenir des clés privées de sources externes.

— wmorrell

À qui d'autre le donne-t-il? Pensez toujours, quel est le pire qui pourrait arriver?

— mckenzm

En fait, je ne pense pas que ce soit si mauvais. Une analogie ci-dessous (Eric Towers) avec donner à l'utilisateur un "mot de passe initial" qui doit ensuite être changé immédiatement est bonne. Parlant d'une expérience personnelle, expliquer aux utilisateurs ce que sont les clés pour la 100e fois peut être un peu fastidieux - l'administrateur est toujours humain. Vous donner la clé privée est paresseux - oui, mais rien ne peut vous empêcher de la remplacer vous-même. En substance, une fois qu'il vous l'a envoyé, vous n'avez plus besoin de déranger le sysadmin (à moins qu'il n'ait choisi de désactiver les autorisations d'écriture sur le fichier ... alors, agacez-les simplement).

— Ray

@matthiash cette question s'adapte à ce site mais, tout comme un info, il existe un site de sécurité de l'information pour d'autres questions de sécurité.

— topher

Je voudrais également souligner que c'est également ainsi qu'AWS le fait. Lorsque vous créez une instance, vous n'y téléchargez pas votre clé publique, une paire de clés est générée pour vous et vous téléchargez la clé privée.

— GnP

Réponses:

C'est exactement comme vous le dites: le concept global de l'authentification par clé publique est que la clé privée ne doit être connue que du propriétaire, tandis que la clé publique correspondante peut être largement diffusée. La sécurité de votre authentification dépend de la sécurité de la clé privée, pas de la sécurité de la clé publique.

Le fait que quelqu'un d'autre vous fournisse une clé privée la rend automatiquement compromise. (Vous ne savez pas si cet autre administrateur possède toujours une copie qui peut être utilisée pour vous imiter.)

— HBruijn
source

Supposons le meilleur de la part de l'administrateur du serveur et supposons qu'il crée des choses mieux, car il ne ferait pas confiance à l'utilisateur pour ne pas avoir de clé privée compormisée. Peut-être que l'administrateur du serveur pense que la clé privée des utilisateurs est très ancienne et peut-être compromise au fil des ans. C'est la même chose avec U2F, où le consortium ou les fournisseurs ne font pas confiance aux utilisateurs pour générer des clés, c'est pourquoi les appareils U2F sont livrés avec des clés pré-créées!

— cornelinux

L'administrateur doit aider l'utilisateur à générer et à sécuriser une clé privée.

— Alex

Tu as complètement raison. Mais souvent, les administrateurs sont meilleurs avec les ordinateurs qu'avec les humains, -)

— cornelinux

L'administrateur peut vous usurper l'identité de toute façon.

— user253751

Je pense que vous confondez les pratiques théoriques d'un exemple étroit avec la réalité et la vue d'ensemble. Vous devez de toute façon faire confiance à l'administrateur car il a le contrôle du système et peut éviter d'avoir à utiliser la clé. La remise de clés privées se produit dans le monde réel, car les utilisateurs finaux ne comprennent pas comment en créer une, ou comment en créer une en toute sécurité.

— JamesRyan

Pour cette clé, l'organisation n'a pas de non-répudiation . IE, si quelqu'un fait quelque chose d'abus ou de destructeur à ce système en utilisant «votre» clé, l'administrateur ne peut pas vous blâmer d'en être le seul responsable. Étant donné que la personne qui vous l'a donnée avait également la clé. Ce n'est probablement pas si mal pour vous, car cela vous donne une défense, mais horrible pour l'organisation contrôlant le serveur, si quelque chose de mauvais se produit.

Vous pourrez peut-être utiliser les privilèges d'écriture dont vous disposez sur les clés fournies, pour mettre à jour vos clés autorisées, ajouter votre clé et supprimer la clé fournie.

— Zoredache
source

En fait, l'administrateur peut s'attendre à ce que l'utilisateur change sa clé lors de sa première utilisation, tout comme avec les premiers mots de passe générés par l'administration.

— Eric Towers

Comme l'a dit un grand homme , "attendez-vous à loin". Le changement de première utilisation est souvent nécessaire pour les mots de passe, mais n'est jamais nécessaire pour la cryptographie à clé publique - c'est un peu le point.

— womble

@EricTowers Est-il même possible d'exiger avec les implémentations SFTP contemporaines (ou même SSH, à moins que vous ne souhaitiez bricoler quelque chose ensemble)?

— un CVn

Cette réponse donne l'impression que les actions sur sftp sont signées quelque part dans un journal et sécurisées de bout en bout par cette clé. Ce n'est tout simplement pas le cas, un administrateur peut altérer les actions ou les journaux sans même utiliser la clé.

— JamesRyan

@marcelm: Il y a une raison pour laquelle j'ai dit "souvent nécessaire", pas "toujours absolument obligatoire en toutes circonstances sans exception". En tant que personne qui, en fait, demande (et accepte) régulièrement des hachages de mot de passe et des clés publiques, je sais que c'est une barrière beaucoup plus élevée pour amener quelqu'un à fournir un mot de passe haché (avec un sel sécurisé et tout) qu'une clé publique. Si vous avez un client SSH, vous disposez d'un outil de génération de clés. On ne peut pas en dire autant de quelque chose capable d'appeler crypt(2) sous ses nombreuses formes divertissantes.

— womble