Prévoir une perte de mot de passe root (SSH)

Support Debian
#1

Hello tout le monde,

Je suis actuellement en charge de plus de 1500 serveurs (physiques et virtuels confondus) et je suis confronté à une problématique simple.
J’ai besoin de prévoir le cas où le mot de passe root d’un serveur soit modifié ou perdu, rendant impossible toute connexion au serveur.

Jusqu’ici, ma clé publique était déposée dans le fichier authorized_keys du compte root de chaque serveur pour répondre à cette problématique mais une demande de suppression de cette clé a été faite par mes supérieurs (à cause du risque de compromission essentiellement).

Je me tourne donc vers vous pour savoir si vous auriez une autre solution.

PS : il y a toujours la solution de rebooter la machine, et de faire les actions connues du style changer la ligne d’exécution au boot en rajoutant un init=/bin/sh, en passant sur LiveCD etc mais ces solutions ne sont pas envisageables car les serveurs ne doivent pas être éteints.

Merci d’avance :slightly_smiling:

#2

[quote=“OpenPanic”]Jusqu’ici, ma clé publique était déposée dans le fichier authorized_keys du compte root de chaque serveur pour répondre à cette problématique mais une demande de suppression de cette clé a été faite par mes supérieurs (à cause du risque de compromission essentiellement).
[/quote]
Donc, tu retiens maintenant 1500 mots de passe de tête ?
Parce que, si tu les notes dans un fichier, je ne vois pas en quoi il risque moins d’être compromis qu’une clé SSH.

#3

[quote=“kna”]Donc, tu retiens maintenant 1500 mots de passe de tête ?
Parce que, si tu les notes dans un fichier, je ne vois pas en quoi il risque moins d’être compromis qu’une clé SSH.[/quote]
Exactement ce que j’allais dire, rien à rajouter si ce n’est que tes “supérieurs” devraient peut-être réfléchir un peu avant de sortir des âneries plus grosses qu’eux… :mrgreen:

Sinon pour ta question elle-même : perso je ne vois pas comment ça serait possible.

#4

pour avoir aussi un patron qui me demande la lune en deux jours un conseil :

fait lui une présentation ou tu prend en compte les risques (réel et éventuelle).

un planning avec chaque étapes.

un délais au plus court et plus tard (hésite pas à en rajouter un peu… ton patron va toujours te dire que c’est trop long.)

fais une réunion avec une vrais explication des tenant et aboutissant du projet pour le faire réagir sur la criticité de la chose afin que tu gagne de la marge de manoeuvre!!

#5

Merci de vos réponses :slightly_smiling:

Alors, visiblement j’ai fais un petit raccourci dans mon explication qui a mené à une confusion. Je me ré-explique donc.
Nous avons actuellement une application qui gère dors-et-déjà tous les mots de passe de tous les applicatifs de tous les serveurs. Le tout protégé par login/mdp + passphrase et cela fonctionne très bien.

La problématique n’est donc pas le stockage des mots de passe mais la suivante : Imaginons que quelqu’un (nous somme une grosse équipe) modifie le mot de passe root d’une machine et oublie de renseigner l’application de gestion des mots de passe ; ou encore qu’un attaquant modifie un mot de passe root. Nous n’aurons d’autre choix que de couper le serveur pour réinitialiser son mot de passe.

Pour répondre à cette problématique, la solution actuellement en place est que la clé publique d’une paire de clés est déposée automatiquement dans le fichier authorized_keys de root sur chaque nouveau serveur installé. Or, cela n’est plus toléré dans la nouvelle politique de sécurité de l’entreprise.

L’idée est donc de trouver une solution permettant de recouvrer l’accès à un serveur dont le mot de passe root aurait changé sans avoir de clé déposée dans le user root.

J’espère avoir été plus clair :unamused:

#6

De manière sécurisée, ce que tu demandes n’est pas possible.

Je formule ta demande sous d’autres termes :

On aimerait bien avoir un moyen d’ouvrir le coffre fort si jamais on oublie la combinaison.

Cela t’aidera peut être à comprendre l’absurdité de la requête de ton patron.

Au choix, je te fournis deux solutions :

  1. Chalumeau, perceuse, dynamite !
  2. Le code est sur un post-it sur le coté du coffre

Soit, en termes informatiques, rebooter le serveur sur un livecd / clef usb afin de faire sauter le mot de passe root. Seulement, j’ose pas espérer que dans un système d’information aussi critique que le votre, vous ayez accès à la salle serveur sans code/clé/badge (Et que faire si vous les perdez ?), que vous ne pouvez pas booter/rebooter les serveurs sans demande de mot de passe (Et que faire si vous les perdez ?), que vos serveurs ne bootent de toutes façons pas sur support externe sans passer par le bios, qui est lui même, bien sûr, protégé par mot de passe (Et que faire si vous les perdez) !

PS : Autre point important … Un serveur dont on ne connait plus le mot de passe root est un serveur qu’il faut mettre immédiatement hors ligne, puisque personne n’est capable de contrôler ce qui se passe dedans.

PS2 : 1500 serveurs et pas de serveur(s) d’annuaire pour centraliser les comptes, c’est une blague ?

#7

A moins que ce ne soi le serveur lui même qui indique que le mot de passe root (ou autre) ai changer, je ne voie pas trop comment faire.

Sinon, je suis d’accord avec Noop, un annuaire centralisé est encore la meilleur solution.

#8

tu expliques à ton patron l’absurdité d’ enlever la clé sur les serveurs et lui fais signer une décharge que si un n’est plus accessible alors tu ne sera pas responsable et voilà tout.

l’ authentification par clé sera toujours 100…000…fois plus sécurisé que par mot de passe ou n’importe quelle autre solution.
Il suffit de mettre un passe-phrase en béton sur toutes les clés privées.

edit: tu peux aussi suivre la directive de tes supérieurs en autorisant l’ authentification par simple mot de passe, mais au lieu de supprimer la clé dans authorized_keys, tu la remplaces par une autre et toi seul possédera la nouvelle clé privée, ainsi plus de risque de compromission et tu pourras toujours accéder aux serveurs.

#9

Nous avons qq centaines de serveurs, je précise qu’aucun d’entre eux n’est accessible en dehors de notre domaine (accès par VPN), mais certain malins ont changés le mot de passe “root” des machines sur lesquelles ils bossaient, mais les admins ont la parade un user non accessible en SSH, donc il faut déjà se connecter avec un user SSH lambda, faire un su - leusercaché, qui lui a un sudo qui donne accès à root, et après un simple passwd, root retrouve son mot de passe d’origine … le fameux user a le même mot de passe sur tous les serveurs (c’est ça la sécurité :slightly_smiling:)

#10

J’allais faire la même réponse qu’a fait debianhadic: créer un user qui à les droits sudo de changer le mot de passe de root …
C’est débile, mais à question con …
Et pour rigoler, tu appelles ce user rootroot :stuck_out_tongue: