Je suis censé accéder à un serveur afin de lier les serveurs intermédiaires et actifs d'une entreprise à notre boucle de déploiement. Un administrateur de leur côté a configuré les deux instances, puis a créé un utilisateur sur le serveur pour nous permettre de SSH en tant que. C'est ce à quoi je suis habitué.
Dans mon esprit, je leur enverrais maintenant ma clé publique qui pourrait être placée dans leur dossier de clés autorisées. Cependant, au lieu de cela, ils m'ont envoyé un nom de fichier id_rsa
qui contient -----BEGIN RSA PRIVATE KEY-----
un courrier électronique à l'intérieur du fichier . Est-ce normal?
J'ai regardé autour de moi et je peux trouver des tonnes de ressources sur la génération et la configuration de mes propres clés à partir de rien, mais rien sur le fait de partir des clés privées du serveur. Devrais-je utiliser cela pour générer une clé pour moi ou?
Je voudrais demander directement à l’administrateur système, mais je ne veux pas paraître idiot et perdre tout le monde entre nous. Dois-je simplement ignorer la clé qu'il m'a envoyée et leur demander de mettre ma clé publique dans leur dossier autorisé?
-----BEGIN RSA PRIVATE KEY-----
le courrier électronique est la prochaine chose effrayante après avoir vu un utilisateur nommé'); DROP DATABASE;--
dans votre table de noms d'utilisateurs.'); DROP DATABASE;--
tant que nom d'utilisateur dans votre table de base de données - cela montre que vousRéponses:
Ce qui est "dans votre esprit" comme ce qui devrait maintenant arriver est correct.
Le courrier électronique n’est pas un moyen de communication sécurisé. Par conséquent, du point de vue de la sécurité, vous (et eux) devriez considérer que la clé privée est compromise.
En fonction de vos compétences techniques et de votre volonté diplomatique, vous pouvez effectuer plusieurs tâches différentes. Je recommanderais l'un des suivants:
Générez votre propre paire de clés et attachez la clé publique à un courrier électronique que vous leur envoyez, en disant:
Remerciez-les et demandez-leur s'ils s'opposent à ce que vous installiez votre propre paire de clés, car la clé privée qu'ils ont envoyée doit être considérée comme compromise après avoir été envoyée par courrier électronique.
Générez votre propre paire de clés, utilisez la clé qu'ils vous ont envoyée pour vous connecter pour la première fois et utilisez cet accès pour modifier le
authorized_keys
fichier afin qu'il contienne la nouvelle clé publique (et supprimez la clé publique correspondant à la clé privée compromise).En bout de ligne: vous ne ressemblerez pas à un idiot. Mais, l’autre administrateur pourrait très facilement ressembler à un idiot. Une bonne diplomatie pourrait éviter cela.
Modifier en réponse aux commentaires de MontyHarder:
Aucune des mesures que je préconise ne consiste à "réparer les choses sans dire à l'autre administrateur ce qu'il a mal fait"; Je viens de le faire subtilement sans le jeter sous le bus.
Cependant, j'ajouterai que je suivrais aussi (poliment) si les indices subtils n'étaient pas relevés:
la source
Oui, c'est exactement ce que vous devriez faire. Le problème avec les clés privées est qu'elles sont privées , ce qui signifie que vous êtes seul à posséder votre clé privée. Depuis que vous avez reçu cette clé de l'administrateur, il l'a aussi. Ainsi, il peut vous imiter à tout moment.
Peu importe que la clé vous ait été envoyée via un canal sécurisé ou non: même si vous avez reçu votre clé privée en personne, cela ne changerait rien. Bien que je sois d’accord avec les commentaires selon lesquels l’envoi par courrier électronique de clés de cryptographie sensibles est la cerise sur le gâteau: votre administrateur ne prétend même pas qu’une politique de sécurité est en place.
la source
/var/log/secure
ou similaire , je suis à peu près sûr que le tour de l'espace ne va pas tromper celui-ci.Pour moi, il semble que l’administrateur ait généré une paire de clés privée / publique pour vous, ajouté la clé publique à allowed_keys et vous envoie la clé privée. De cette façon, vous ne devez utiliser cette clé privée que pour vos sessions SSH avec le serveur. Inutile de générer vous-même une paire de clés ou d'envoyer à l'administrateur une clé publique sur votre clé privée éventuellement corrompue (pensez toujours au pire des cas: P).
Cependant, je ne ferais pas confiance à la clé privée qui vous est envoyée via un courrier non chiffré.
Mon approche serait la suivante: utilisez la clé privée pour vous connecter une fois, ajoutez votre propre clé publique à la authorised_keys sur le serveur (en remplacement de la clé publique d'origine) et jetez cette clé privée d'e-mail. Vous pouvez ensuite remercier l’administrateur qui vous a fourni la clé privée, mais vous préféreriez que ces informations / clés ne soient pas envoyées par courrier électronique (/ du tout).
la source
-i
la ligne de commande pour choisir la clé privée à utiliser.authorized_keys
(après avoir ajouté + testé votre propre).