SSH: sûr pour le client d'héberger une clé RSA privée?

Est-il sûr de générer une paire de clés publique / privée sur le serveur, d'ajouter la clé publique à la liste des clés autorisées, puis de copier la clé privée sur chaque client, comme décrit ici ( http://www.rebol.com/docs/ ssh-auto-login.html ) En supposant que vous gardiez un contrôle permanent sur chaque client? (c.-à-d. même utilisateur, plusieurs ordinateurs).

La procédure typique consiste à générer la paire de clés publique / privée sur le client, puis à ajouter la clé publique du client à la liste des clés autorisées sur le serveur, comme décrit ici ( http://www.linuxproblem.org/art_9.html ). Avec cette méthode, si vous avez plusieurs ordinateurs clients, chacun doit être concaténé à la liste des clés autorisées et maintenu dans le temps.

Félicitations, vous avez trouvé un tutoriel Internet avec de mauvais conseils.

Le problème lié à l'utilisation d'une seule paire de clés pour plusieurs ordinateurs se produit lorsque l'un des ordinateurs est compromis. Ensuite, vous n'avez pas d'autre choix que de révoquer la paire de clés partout et de ressaisir chaque ordinateur qui utilisait cette paire de clés. Vous devez toujours utiliser des paires de clés uniques par machine et par utilisateur, pour limiter les dommages qu'une clé compromise peut faire.

En ce qui concerne ce tutoriel, il est incroyablement mauvais de générer la paire de clés sur le serveur et de copier la clé privée sur le client . C'est entièrement en arrière. Au lieu de cela, la paire de clés doit être générée sur le client et la clé publique copiée sur le serveur. Il existe même un script d'aide ssh-copy-idqui fait exactement cela, et en cours de route s'assure que toutes les autorisations sont correctes, le client obtient la clé d'hôte du serveur, etc.

Il peut en effet y avoir des situations où vous souhaitez gérer de manière centralisée les clés d'identité des utilisateurs, par exemple pour les scripts automatisés, mais dans ce cas, vous devez vraiment le faire à partir d'un troisième hôte, ou idéalement à partir d'un système de gestion de configuration tel que marionnette.

Le plus gros problème avec le protocole décrit dans ce tutoriel est qu'il ne spécifie pas comment vous "téléchargez la clé privée sur la machine cliente" de manière sécurisée (c'est-à-dire qui empêche l'écoute clandestine). Si vous ne disposez pas déjà d'un canal sécurisé, la clé sera vraisemblablement transférée en clair sur Internet (HTTP, FTP, e-mail, etc.). Vous pouvez utiliser HTTPS, mais si vous n'avez pas de vrai certificat, il peut être MITM de renifler la clé. Faites-le comme vous êtes censé le faire; générez la paire de clés sur la machine cliente, transférez la clé publique sur le serveur et n'oubliez pas de vérifier une somme de contrôle du fichier pour vous assurer qu'il n'a pas été modifié lors du transfert.