Existe-t-il un moyen sûr de stocker les mots de passe utilisés pour ssh par un script?

Donc, d'abord, je sais, je devrais utiliser l'authentification par clé avec SSH. Pas besoin de m'expliquer ça.

Le problème ici est que j'ai un (gros) groupe de serveurs, et j'ai besoin d'un script pour pouvoir connecter chacun d'eux.

J'utilise une authentification par clé chaque fois que je le peux, mais ce n'est pas possible sur tous les serveurs (je n'ai aucun contrôle sur cela). Donc SSH avec login, ou parfois telnet.

Donc, pour certains, je viens de stocker les mots de passe dans une base de données, et mon script va les prendre en cas de besoin. Le problème est qu'il ne semble pas vraiment sûr de le faire de cette façon. Existe-t-il un moyen de le rendre un peu plus sûr?

Vous aimez un moyen spécifique de le stocker?

ssh password password-management

— wokati
source

Variables Env. Duplicate from SO: stackoverflow.com/a/4410137/2579527

— Travis Stoll

Les variables d'environnement @TravisStoll ne sont pas sécurisées.

— Jenny D

Je crains que pour votre configuration, le stockage des mots de passe dans une base de données soit à peu près aussi sécurisé que possible. Vous pouvez en faire une base de données chiffrée, comme un fichier keepass (je pense qu'il y a au moins un module perl pour accéder aux bases de données keepass), mais vous devrez toujours stocker le mot de passe dans la base de données quelque part, si vous ne voulez pas entrer à chaque fois que vous invoquez votre script. Peut-être un peu mieux, si vous entrez le mot de passe maître à chaque fois que vous invoquez votre script.

— Isaac

Même si vous utilisez des clés d'authentification SSH au lieu de mots de passe, ce n'est pas une garantie de sécurité - quiconque peut voler votre base de données de mots de passe pourrait simplement voler votre clé privée. Vous pouvez crypter votre clé privée comme vous pourriez crypter votre base de données de mots de passe, mais comme votre script doit déverrouiller la clé (ou la base de données de mots de passe), il est toujours vulnérable à un attaquant. L'utilisation de mots de passe au lieu de clés augmente un peu votre vulnérabilité car elle ouvre davantage de voies pour voler le mot de passe, mais même l'utilisation de clés au lieu de mots de passe n'est pas une sécurité parfaite.

— Johnny

"parfois telnet" semble impliquer que le mot de passe sera parfois même transféré en clair sur le fil ...?

— Hagen von Eitzen

Réponses:

Si votre script peut se connecter à l'un de ces serveurs, toute personne ayant accès au script (ou un accès privilégié à la machine sur laquelle le script s'exécute) peut se connecter à l'un de ces serveurs.

Si le script doit s'exécuter de manière autonome, tous les paris sont désactivés. La réponse est non, il n'y a pas de moyen absolument sûr de stocker les mots de passe dans un tel environnement . Il n'y a aucun moyen absolument sûr et pratique de faire quoi que ce soit.

Au lieu d'essayer d'éviter l'inévitable, vous devriez vous concentrer sur la défense en profondeur .

Bien sûr, vous devez bien sûr protéger les mots de passe de manière adéquate . Cela signifie généralement de les conserver dans un fichier distinct de votre script et de configurer des autorisations de système de fichiers restrictives . C'est à peu près tout ce que vous pouvez faire sur ce front, du point de vue de la sécurité.

D'autres mesures peuvent très certainement ajouter de l' obscurité au processus. Le chiffrement des mots de passe obligera l'attaquant à rechercher la clé de déchiffrement. L'utilisation d'une sorte de stockage protégé par le système d'exploitation protège généralement contre les autres utilisateurs accédant à votre clé (il n'offre donc aucun avantage sur les autorisations du système de fichiers, autre que d'être complexe à attaquer - et à utiliser). Ces mesures retarderont une attaque, mais ne l'empêcheront certainement pas contre un attaquant déterminé.

Maintenant, considérons les mots de passe comme publics pendant un moment. Que pouvez-vous faire pour atténuer les dommages?

Une solution ancienne et testée consiste à restreindre ce que ces informations d'identification peuvent faire. Sur un système UNIX, une bonne façon de procéder consiste à configurer un utilisateur distinct pour votre script et à limiter les capacités de cet utilisateur , à la fois sur les serveurs d'accès et sur les serveurs auxquels vous avez accédé. Vous pouvez limiter les capacités des utilisateurs au niveau SSH, au niveau du shell ou éventuellement en utilisant un mécanisme de contrôle d'accès obligatoire comme SELinux .

Vous pouvez également envisager de déplacer la logique de script dans les serveurs . De cette façon, vous obtenez une interface plus petite qui est plus facile à contrôler, et surtout à ...

Moniteur . Surveillez toujours l'accès aux serveurs. De préférence, authentification du journal et commandes exécutées dans un journal d’ajout uniquement . N'oubliez pas de surveiller les modifications du fichier de script à l'aide auditd, par exemple.

Bien sûr, beaucoup de ces mécanismes ne sont pas utiles si vous n'avez aucun contrôle sur les serveurs, comme votre question semble impliquer. Si tel est le cas, je vous conseille de prendre contact avec les personnes administrant les serveurs et de leur faire connaître votre script et les pièges de sécurité potentiels.

— goncalopp
source

La réponse courte est non.

La réponse longue est: non, il n'y a pas de moyen complètement sûr. (Cela inclut les variables d'environnement, qui peuvent être consultées par d'autres sur le serveur.) Le plus proche que vous pouvez obtenir est de les stocker dans un format crypté - keepass, un fichier crypté GPG ou autre chose dans ce sens. Mais à un moment donné, vous devez décrypter le mot de passe pour que votre script puisse l'utiliser, et à ce stade, vous serez vulnérable.

En d'autres termes, vous devez vous pencher longuement sur la sécurité approfondie, à la fois sur le serveur à partir duquel le script est exécuté, sur le réseau et sur les serveurs cibles.

— Jenny D
source

Je ne suis pas sûr que ce soit un NON définitif. Sa session est sécurisée; le système de fichiers pourrait être sécurisé, avec les autorisations appropriées définies; donc s'il peut obtenir des choses du système de fichiers (un mot de passe stocké) et les diriger via stdin vers la commande ssh, il devrait être ok, non? Veuillez consulter les liens que j'ai donnés dans un autre commentaire ci-dessus. Qu'est-ce que tu penses?

— pgr

S'il les envoie via stdin, il y a une vulnérabilité. Avec vos suggestions, ce sera plus sûr, mais ce ne sera pas complètement le cas. Surtout étant donné que certaines sessions se font sur telnet.

— Jenny D

Vous pouvez crypter les mots de passe dans votre base de données avec un deuxième mot de passe et stocker ce mot de passe sur une machine distincte (3e) et avoir un système en place où le script qui doit sortir les mots de passe de la base de données connecte d'abord cette 3e machine pour obtenir le mot de passe de décryptage , déchiffre le mot de passe dans la base de données avec le mot de passe qu'il a obtenu de la 3ème machine et ça marche.

Bien sûr, cela n'ajoute pas vraiment de sécurité supplémentaire, un attaquant disposant de privilèges suffisants pourrait également simplement demander le mot de passe à la 3e machine.

Mais le fait est qu'un tiers peut contrôler la 3e machine, par exemple votre patron ou responsable de la sécurité, ou le tiers contrôlant les serveurs que vous ne contrôlez pas.

De cette façon, vous pouvez leur dire, s'ils ont un problème, si vous quittez votre travail et qu'ils ne font pas confiance au gars qui vous remplace, ou s'ils veulent juste que vos scripts cessent d'accéder à leurs machines, ils peuvent débrancher le 3 l'ordinateur et vos scripts n'auront plus accès aux mots de passe.

— Jens Timmerman
source