Dois-je créer une nouvelle clé ssh privée sur chaque système?


10

Je dois me connecter à plusieurs serveurs à partir de plusieurs appareils via SSH. Je me demande si je devrais créer un nouveau fichier id_dsa sur chaque appareil à partir duquel je me connecte, ou s'il n'y a pas de problème pour copier le même fichier id_dsa sur chaque appareil.

Par exemple, j'ai mon système de bureau principal basé sur Ubuntu et un MacBook Pro avec ssh. Et j'ai un Netbook basé sur Windows avec Putty installé. Et j'ai un téléphone Android avec ConnectBot. À partir de n'importe lequel de ces appareils, je pourrais avoir besoin de SSH pour des dizaines de serveurs physiques et virtuels différents.

Chaque serveur a besoin que ma clé publique soit installée. De plus, mes comptes GitHub et Codaset nécessitent ma clé publique.

Pour simplifier la gestion des clés, je pense utiliser la même clé privée sur tous ces systèmes. Est-ce une pratique courante ou vaut-il mieux avoir une clé privée sur chaque système?

Réponses:


3

Si vous utilisez la même clé publique sur chaque système et que la clé privée est compromise, tout système utilisant cette clé, sauf autres restrictions, sera accessible.

J'espère que vous utilisez des clés privées protégées par mot de passe?

Dans notre pratique de gestion, nous avons des «rôles» de sécurité faible, moyen et élevé. Chaque rôle utilise une clé différente. Les clés privées de haute sécurité ne doivent jamais être transmises à des actifs externes, utilisées sur des ordinateurs portables qui pourraient être perdus / volés, etc. Les clés de sécurité moyenne et faible peuvent être déployées dans un plus large éventail de scénarios.

Je suggère d'examiner vos modèles d'utilisation et de voir ce qui se passe depuis en termes de rôles de sécurité. Quels sont les dommages causés par l'obtention de votre clé privée?

Avez-vous envisagé de placer votre clé privée SSH sur un périphérique matériel à partir duquel elle ne peut pas être volée, supprimant le compromis potentiel de la clé dans un non-problème?

Les modules de sécurité matérielle et les cartes à puce peuvent être utilisés pour stocker les clés privées SSH de manière sécurisée, permettant à toutes les opérations cryptographiques d'être effectuées sur l'appareil, plutôt que sur vos systèmes d'exploitation. Cependant, ils ne sont pas une panacée, car ils nécessitent également des périphériques matériels de sauvegarde, en cas de défaillance matérielle.


Oui, mes clés sont protégées par mot de passe. Merci pour votre réponse. Vous avez aidé à confirmer ma préoccupation que si j'utilisais la même clé sur tous mes appareils, cela pourrait entraîner de plus gros problèmes en cours de route.
Tauren

2

Absolument. Vous pouvez toujours ajouter toutes les clés à votre fichier authorized_keys2. J'aime la suggestion de jeffatrackaid. Cependant, j'utiliserais des clés privées différentes pour chaque appareil - pourquoi pas. Perdez votre Android. Simple, supprimez la clé de la liste des clés autorisées. Si vous ne le faites pas, vous devrez à nouveau régénérer ce niveau de clé.

Cela dit, cela dépend de la façon dont vous percevez le risque de ces actifs. Évidemment, vous ne voulez pas perdre les clés, mais certaines peuvent être exposées à un risque plus élevé, par exemple github vs root pour vos vps, par exemple.


FYI, authorized_keys2est obsolète depuis 2001 - OpenSSH utilise maintenant authorized_keys(bien qu'il lit toujours les deux fichiers pour la compatibilité)
user1686

Ah ok merci. Je tiens toujours à désactiver SSHv1 et les chiffrements à faible résistance, etc.

2

Vous souvenez-vous quand Debian a eu ce petit problème d'entropie lors de la génération de clés SSH? C'est alors que j'ai bien appris ma leçon.

J'ai ma propre clé privée pour mes propres trucs, comme accéder à mes serveurs personnels. J'ai ma clé «tout usage» qui me permet d'accéder à la plupart de mes boîtes de développement, puis je coupe les clés par client que je gère.

Je garde également une liste très détaillée des clés sur quelles machines, au cas où je devrais les remplacer ou les retirer à la hâte.

Pour tout ce qui est sérieux, j'utilise simplement LDAP / PAM, au cas où je devrais retirer quelqu'un d' autre à la hâte.

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.