Existe-t-il une paire de clés SSH signée?

9

Nous transférons des fichiers vers un serveur distant dans notre application et la méthode d'authentification requise consiste à utiliser des clés SSH.

J'ai donc créé ma paire de clés à l'aide de ssh-keygen et soumis ma clé publique pour l'insertion dans le fichier authorized_keys de l'hôte distant. Cependant, cela a été rejeté par la sécurité informatique qui a déclaré qu'ils généreraient la paire de clés pour moi et m'enverraient la clé privée. Raison: "Nous avons besoin que les clés SSH soient signées par l'équipe de sécurité informatique. C'est pour nous assurer d'avoir une certaine avance dans les suivis et la responsabilité."

De toute évidence, j'ai des problèmes avec cela. Avoir la clé privée générée par quelqu'un d'autre signifie que je peux avoir cette personne se faisant passer pour moi sans que je le sache. J'essaie de trouver des moyens de réfuter cet argument.

Pour autant que je puisse google, il ne semble pas y avoir de moyen connu de signer les clés de telle sorte que cela aide à suivre une personne qui s'est connectée. Le fait que j'ai soumis ma clé publique signifie que je possède la clé et que toute personne qui se connecte au serveur distant avec cette clé est par défaut identifiée comme moi-même. En quoi la signature aiderait-elle? Et comment signeraient-ils de toute façon?

Quelqu'un s'il vous plaît me donner des indices si je me trompe, merci!


Ok, maintenant que nous avons déterminé qu'il n'y a aucun moyen de signer les clés SSH, je dois montrer à la sécurité informatique comment ils peuvent réellement garder une trace de qui s'est connecté (je dois être constructif, je suppose, si ce n'est pas le début ). Sur mon propre serveur, j'ai défini LogLevel de sshd sur DEBUG. Alors maintenant, lorsque je me connecte, je peux voir l'extrait de code suivant:

Found matching DSA key: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

Cela semble être une valeur de hachage. Comment puis-je relier cela à la clé publique du fichier authorized_keys qui a été utilisée? Je sais qu'il y a une autre ligne qui dit:

debug1: matching key found: file /home/bofh/.ssh/authorized_keys2, line 1

mais ce n'est pas aussi utile que les numéros de ligne peuvent être facilement modifiés si je devais insérer une clé en haut du fichier, en poussant les clés d'origine vers le bas.

Merci!

feicipet
la source
2
Peut-être qu'ils imprimeront les clés, les signeront (sur papier) et les classeront ensuite?
innaM
La valeur de hachage que vous obtenez est probablement la soi-disant empreinte digitale de la clé. Je recommande de consulter le manuel openssh pour savoir comment répertorier ces empreintes digitales.
Niels Basjes
La raison la plus probable pour laquelle cette politique est en place est qu'ils veulent réellement pouvoir vous faire passer pour une personne si nécessaire. L'argument de la signature est juste BS pour le rendre plausible aux néophytes. Même s'ils devaient signer la clé de pub, ils n'auraient pas besoin de la générer eux-mêmes.
b0fh

Réponses:

13

Depuis que vous avez posé votre question, l'univers a changé.

Openssh5.4 a ajouté un support pour exactement le type de certificats que vous recherchiez. Voir les notes de version à http://www.openssh.org/txt/release-5.4 (et les pages de manuel) pour plus d'informations, ou si vous voulez vraiment être fou, regardez PROTOCOL.certkeys pour les détails sanglants

James Polley
la source
Je viens de voir ça après très longtemps ... semble légitime :) Je vais essayer, merci!
feicipet
8

Ma première impression en lisant votre question est que l'informatique a mélangé SSH et SSL (cela doit être signé par nous) et ne comprend pas non plus comment la signature SSL fonctionne vraiment.

Quoi qu'il en soit, il n'y a aucun moyen de signer une clé SSH (à ma connaissance).

Niels Basjes
la source
+1 vous ne pouvez pas signer les clés ssh de la même manière que vous pouvez signer les certificats PGP ou SSL. Je voudrais leur demander des éclaircissements.
David Pashley
4

Quelque chose ne va pas dans cette demande.

S'il fournit des fichiers signés au serveur,
je m'attends à ce que cela soit fait au strict minimum.

  1. Vous créez une paire de clés pour vous-même (appelez cela ma clé)
    • Lorsque vous voulez envoyer quelque chose,
    • vous le cryptez d'abord avec my-key-private
    • puis téléchargé sur le serveur ce fichier crypté
    • Quelqu'un sur le serveur doit inverser le processus comme ceci,
    • ils utilisent votre my-key-pubpour décrypter le fichier
    • si vous avez envoyé le fichier, le décryptage le récupérera
    • sinon, ils n'obtiendront aucun fichier utilisable
    • efficacement, vous avez signé le fichier avec votre clé privée
    • ils ont vérifié la signature avec votre clé publique
    • la responsabilité est effectuée par eux confirmant que vous avez envoyé le dossier

Il existe d'autres façons de procéder,
mais obtenir une paire de clés générée par quelqu'un d'autre est inutile comme schéma d'authentification .
Cela implique fortement que vous leur faites confiance autant que vous vous faites confiance.


Ce sont les premières questions que vous pouvez poser à votre service informatique.
Si la responsabilité est une préoccupation pour l'informatique,

  1. Comment s'assurent-ils que vous ne partagez pas / perdez la paire de clés qu'ils vous ont donnée? et,
    • En quoi ce concept de paire de clés de l'informatique est-il différent d'un mot de passe qui vous a été donné par l'informatique
      Pourquoi s'embêter avec des paires de clés dans ce cas.
nik
la source
Vous pensez à PGP / GnuPG pour crypter des fichiers. Dans ce cas, la signature des clés est normale. La question d'origine concerne les clés SSH. Cela aurait du sens s'ils demandaient une clé SSH signée / chiffrée PGP (après avoir vérifié et signé les clés PGP de l'autre).
pages
@pgs, j'essaie de voir ce que l'informaticien vise ici.
nik
Je suis presque sûr que le gars de la sécurité est confus, mais comme il est le gars de la sécurité informatique de l'entreprise de mon client et non de mon collègue, je dois être un peu plus tact et pousser de manière constructive sans me moquer de lui et dire qu'il a des choses mélangé. Oui, c'est définitivement SSH et non PGP.
feicipet
@feicipet, faire preuve de tact est l'endroit où mes derniers points vous aideront.
nik
@feicipet, votre objectif serait de leur faire enfin réaliser le minimum qu'ils devraient faire pour réaliser correctement leur intention.
nik
2

Il n'y a aucune raison pour que vous ne puissiez pas utiliser les certificats X.509 pour l'authentification SSH au lieu des clés nues - en fait, je préférerais de beaucoup que OpenSSH fonctionne de cette façon! Mais, la version stock d'OpenSSH ne le fait pas, et c'est l'implémentation dominante de nos jours.

J'ai vu quelques versions corrigées d'OpenSSH flotter autour, et l'implémentation commerciale SSH.com semble également prendre en charge l'authentification X.509. Donc, si votre organisation en utilise un, exiger que les clés soient signées par une autorité centrale serait tout à fait logique.

Cela dit, il n'y a aucune excuse pour exiger que la clé privée soit générée par un tiers! S'ils optent pour la route X.509, ils devraient vous demander de générer une paire de clés et une demande de signature de certificat, comme vous le feriez avec tout autre certificat X.509 utilisé pour SSL, etc.

Stephen Veiss
la source