Quelle est la gravité d'avoir plusieurs appareils avec les mêmes clés de serveur SSH?


21

Je travaille sur un périphérique intégré qui exécute FreeBSD et SSH.

Comme vous le savez, sshd aime générer aléatoirement un jeu de clés de serveur lors de son premier démarrage. Le problème est que nous expédierons le produit avec un système de fichiers en carte SD en lecture seule (non négociable).

Mes deux options telles que je les vois sont:

  • Expédiez les mêmes clés de serveur sshd sur tous les appareils
  • Montez un système de fichiers mémoire et générez les clés du serveur à chaque démarrage (lent ...)

Est-ce un problème de sécurité majeur d'envoyer les mêmes clés de serveur sur tous les appareils? Ces éléments ne seront pas directement sur Internet. Il y aura parfois plusieurs appareils appartenant à la même personne et sur le même réseau.

La plupart du temps, l'appareil n'est pas connecté à Internet.

La connexion avec SSH ne fait pas partie du fonctionnement normal. C'est principalement pour la commodité des programmeurs et des techniciens. Les clients ne se connecteront pas à l'appareil avec SSH.

Quelles sont les ramifications de l'utilisation des mêmes clés de serveur sur plusieurs périphériques matériels?

PS: quelqu'un pourrait-il créer une balise Internet des objets?

EDIT : Je parle d'installer les mêmes clés privées d'hôte sur tous les serveurs (appareils). En ce qui concerne les clés publiques / privées des utilisateurs, il n'est actuellement pas prévu d'utiliser la connexion basée sur les clés - ce serait la connexion par mot de passe. Encore une fois, même mot de passe sur tous les serveurs (appareils).

Je sais que c'est probablement une mauvaise idée. J'aimerais savoir pourquoi c'est précisément une mauvaise idée pour que je puisse comprendre les compromis.


Si vous voulez dire les clés d'hôte, les utilisateurs avec plus d'un de vos appareils peuvent recevoir des avertissements en fonction de la configuration de leur client ssh. les plus grandes préoccupations concerneraient les clés d'authentification ssh réelles. Espérons que vous n'installez aucune clé privée et que vos clés publiques soient limitées à des réseaux sources spécifiques et que vos clés privées appartenant à vos techniciens aient une phrase de passe forte et que ces clés ne soient jamais enregistrées dans un référentiel par erreur. Les IoT obtiennent une très mauvaise réputation à cause de ces choses. Ne pas dire que vous le feriez, simplement dire que c'est un gros problème.
Aaron

Je parle d'installer la même clé privée d'hôte sur tous les serveurs, si c'est ce que vous voulez dire.
NXT

2
L'utilisation du même nom d'utilisateur / mot de passe sur tous les appareils est une très mauvaise idée. Celles-ci sont beaucoup plus faciles à utiliser en force brute que la clé privée utilisée pour l'authentification par clé publique. Même si ces appareils ne sont pas censés être directement connectés à Internet, quelqu'un le fera quand même. Et si "pas directement connecté" signifie NAT, ils sont suffisamment connectés ...
Tero Kilkanen

7
Le partage de la clé SSH signifie qu'une personne qui peut accéder à la clé privée sur un appareil peut emprunter l'identité de tous ces appareils.
user253751

3
Bien que ce soit une question intéressante, je ne vois rien à ce sujet qui se rapporte à l'administration du système, et est donc hors sujet pour Server Fault. Vous posez des questions sur la conception d'une interface de débogage / diagnostic pour un périphérique intégré que vous expédiez, et non sur une interface qui serait pertinente pour les administrateurs système. Cette question pourrait être migrée vers la sécurité de l'information .
200_success

Réponses:


27

Plutôt que de stocker des données spécifiques à l'hôte telles que les clés d'hôte ssh sur la carte SD ou d'autres supports en lecture seule, vous pouvez les stocker dans la NVRAM, ce à quoi elles sont destinées sur un système intégré. Vous devrez effectuer des scripts personnalisés pour stocker et récupérer les clés au démarrage, mais les scripts seront exactement les mêmes pour chaque appareil.


12

L'impact de l'envoi de la même paire de clés avec tous vos appareils est directement lié à la sécurité des clients qui s'y connectent, car cela signifie qu'il n'y a aucun moyen (à partir d'un client SSH) d'identifier de manière unique l'appareil auquel il peut se connecter. En cas de fuite de votre paire de clés, elle pourrait être utilisée pour les attaques MITM.

D'autre part, la régénération des clés à chaque démarrage déclenchera également une alerte sur les clients.

Pour référence, à partir de man ssh(1):

sshgère et vérifie automatiquement une base de données contenant l'identification de tous les hôtes avec lesquels il a déjà été utilisé. Les clés d'hôte sont stockées dans ~/.ssh/known_hostsle répertoire personnel de l'utilisateur. En outre, le fichier /etc/ssh/ssh_known_hostsest automatiquement vérifié pour les hôtes connus. Tous les nouveaux hôtes sont automatiquement ajoutés au fichier de l'utilisateur. Si jamais l'identification d'un hôte change, l' sshavertit et désactive l'authentification par mot de passe pour empêcher l'usurpation de serveur ou les attaques man-in-the-middle, qui pourraient autrement être utilisées pour contourner le cryptage. L' StrictHostKeyCheckingoption peut être utilisée pour contrôler les connexions aux machines dont la clé d'hôte n'est pas connue ou a changé.


2
Je ne comprends pas pourquoi ils ne peuvent pas générer une seule fois (sur chaque appareil, au premier démarrage) puis ne plus générer (à moins qu'ils ne soient supprimés)?
djsmiley2k - CoW

Parfaitement faisable. Mais l'OP déclare qu'il / elle veut: «Monter un système de fichiers mémoire et générer les clés du serveur à chaque démarrage». Donc ma réponse suppose cela.
dawud

ah ouais j'ai raté ça quand je l'ai lu la première fois.
djsmiley2k - CoW

5

Il semble que dans la première option, les clés SSH soient disponibles sur la carte SD. Ainsi, tout utilisateur peut prendre la carte et la lire. Donc, fondamentalement, vos clés privées sont devenues (principalement) publiques.

Cela permettra des attaques d'homme au milieu, comme les suivantes:

  1. Un utilisateur configure un serveur SSH avec les clés privées obtenues à partir de votre appareil et donne cette adresse IP à votre technicien.
  2. Votre technicien saisit le mot de passe root via la connexion SSH.
  3. L'utilisateur connaît désormais le mot de passe root valide pour tous vos appareils.

Cependant, vous ne devriez pas utiliser les mots de passe root en premier lieu, utilisez plutôt les clés ssh pour l'authentification. L'impact des clés de serveur partagées est alors assez faible si vous vous connectez uniquement à partir d'un LAN.

SSH fournit également une confidentialité directe, de sorte qu'un attaquant doit être en mesure de configurer un faux serveur pour bénéficier des clés; renifler passivement le trafic ne permettra pas de le décrypter.


C'est drôle comme nos idées préconçues peuvent nous (moi) aveugler. La carte SD est à l'intérieur de l'unité derrière un panneau et sous une carte de circuit imprimé, il ne m'est donc jamais venu à l'idée que quelqu'un la retirerait. Cependant, vous avez raison, il est absolument accessible à toute personne possédant un tournevis. Merci pour le rappel de considérer la sécurité physique du système.
NXT

WRT # 2, le mot de passe root ne doit pas être envoyé via la connexion SSH. Il doit être entré dans le client terminal et utilisé pour la moitié locale d'un protocole d'authentification qui prouve la possession du secret sans le transmettre ("preuve de connaissance"). Même des systèmes vieux de plusieurs décennies savaient envoyer un hachage du mot de passe et non le mot de passe lui-même. Incluez un nonce dans le protocole challenge / réponse, et l'attaquant ne connaît ni le mot de passe d'origine ni aucun jeton pouvant être utilisé à sa place.
Ben Voigt

1
@BenVoigt Je pense que la plupart des systèmes Unix transmettent le mot de passe au serveur. Le fichier fantôme stocke uniquement un hachage, mais vous ne voulez pas faire confiance à un hachage généré par le client - car sinon, n'importe qui pourrait se connecter avec un hachage volé, sans l'inverser. Le serveur doit donc connaître le mot de passe réel pour exécuter bcrypt ou similaire sur celui-ci.
jpa

2

J'ai lu ça avec horreur! Moi qui ai fait plusieurs machines dans le même cluster avec la même clé d'hôte ssh, je n'oserais jamais faire ça. N'autorisez en aucun cas des machines avec différents ensembles d'administrateurs à partager des clés d'hôte ssh. De cette façon réside la folie et l'horreur hurlante lorsque vous êtes posté pour votre manque de sécurité.

Voici, je vous dis la vérité, celui qui compromet un appareil les compromet tous. Une fois obtenu, attendez-vous à ce que les mauvaises personnes sautent de l'une à l'autre à volonté et que la sécurité revienne comme si c'était du papier mince.


1
Pourriez-vous expliquer comment un attaquant utiliserait une clé privée de serveur volée pour compromettre d'autres appareils?
jpa

@jpa: Pour les clés d'hôte, en interceptant et en volant des mots de passe, etc. De plus, cette configuration semble proposer de faire la même chose avec les clés d'utilisateur.
joshudson

1

Étant donné que vous mentionnez que l'accès SSH n'est pas utilisé par l'utilisateur final / le client, vous souhaiterez peut-être désactiver l'accès SSH par défaut et ne l'activer que temporairement lorsque l'appareil est mis en mode «débogage».

Vous pouvez alors soit expédier tous les appareils avec la même clé, en supposant que vous avez protégé le mode "débogage" afin qu'il ne puisse pas être déclenché à distance par quelqu'un essayant de pirater l'appareil.

Ou vous avez une nouvelle clé générée lorsque l'appareil passe en mode «débogage» - vous n'avez donc pas à perdre de temps au démarrage à générer les clés à chaque mise sous tension de l'appareil.


J'aime cette idée.
NXT

1

Voici un exemple de scénario d'attaque basé sur les contraintes que vous avez:

Si vos appareils le sont, dites un Raspberry Pi par exemple. Si je monte et tire la carte SD d'une carte, je peux la coller dans mon propre ordinateur, trouver la clé sshd et la copier partout où je veux. Peut-être que je prends mon propre Raspberry Pi et une carte Ethernet USB. Maintenant, je peux coller cela entre un appareil cible et où qu'il aille et surveiller les connexions ssh. Quand je vois que le périphérique cible essaie d'établir une connexion ssh, je fais ceci:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

Oh, c'est quoi ça? Votre mot de passe est "j'aime les chats"? C'est un email intéressant que tu as envoyé à ta femme. Je parie que ce serait encore plus intéressant si elle lisait ce courriel que vous avez envoyé à votre épouse voisine.

Les possibilités sont infinies . Et la cible ne le saurait jamais, car la clé sshd est identique à celle trouvée sur le vrai serveur. Selon la sécurité physique des installations qui reçoivent votre appareil, cela pourrait être incroyablement trivial. Ne fais pas ça.

Au lieu de cela, faites ce que vous proposez déjà mais corrigez-le . Avant d'écrire votre image, exécutez quelque chose comme ceci:

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

Et maintenant, chaque serveur a une nouvelle clé. Parce que vous ne voulez vraiment, vraiment pas distribuer des copies d'une clé. Je veux dire honnêtement que c'est au moins aussi mauvais que de prendre une photo de vos clés de maison et de les télécharger sur Internet avec votre adresse personnelle.


1
Si quelqu'un a un accès physique à votre matériel et que vous ne cryptez pas les données au repos, tous les paris sont désactivés.
user9517 prend en charge GoFundMonica
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.