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

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.

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.

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é.

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.

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.

É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.

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.