# \[Clé SSH\] Renouvellement de parc **URL:** \ **Category:** Support Debian\ **Created:** [Juillet 19, 2018, 1:22 UTC](https://www.debian-fr.org/t/cle-ssh-renouvellement-de-parc/77240 "2018-07-19T13:22:24Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![checkout](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/8edcca/32.png) [@checkout](https://www.debian-fr.org/u/checkout)\ **Post date:** [Juillet 19, 2018, 1:22 UTC](https://www.debian-fr.org/t/cle-ssh-renouvellement-de-parc/77240/1 "2018-07-19T13:22:25Z")
Bonjour, Je dispose de plusieurs machines sur un parc donné, toutes sous debian 9.4. J’ai un serveur central qui exécute des scripts régulièrement sur toutes les machines en passant par la clé ssh. Le problème que je rencontre est dès que je dois remplacer physiquement une machine, après copie de la clé publique, le serveur central ne reconnait pas la nouvelle machine et je dois exécuter un ssh-keygen. Etant donné que les machines sont remplacées régulièrement, est il possible de se passer de cette manipulation ? ---
**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\ **Post date:** [Juillet 19, 2018, 6:37 UTC](https://www.debian-fr.org/t/cle-ssh-renouvellement-de-parc/77240/2 "2018-07-19T18:37:33Z")
Bonjour, Attends, je ne comprend pas ce que tu fais, tu changes la machine, et après, tu fais quoi avec ssh-keygen ? ---
**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\ **Post date:** [Juillet 19, 2018, 8:37 UTC](https://www.debian-fr.org/t/cle-ssh-renouvellement-de-parc/77240/3 "2018-07-19T20:37:52Z")
> [@checkout](#): > > Je dispose de plusieurs machines sur un parc donné, toutes sous debian 9.4. J’ai un serveur central qui exécute des scripts régulièrement sur toutes les machines en passant par la clé ssh. Comment sont gérés les utilisateurs des machines du parc ? En particulier quels sont les identifiants sur le serveur central et sur la machine qui exécute le script ? Est-ce que les répertoires utilisateurs (HOME avec uid \>= 1000 ) sont partagés sur un serveur NFS par exemple ? Est-ce que les utilisateurs qui exécutent les scripts sont des utilisateurs systèmes (uid \< 1000 )? > [@checkout](#): > > Le problème que je rencontre est dès que je dois remplacer physiquement une machine, après copie de la clé publique, le serveur central ne reconnait pas la nouvelle machine et je dois exécuter un ssh-keygen. copie de quelle clé publique ? Cette non reconnaissance d’une nouvelle machine est-elle due au fait que la commande `ssh` ne retrouve pas le nouveau nom et la nouvelle IP dans un fichier `~/.ssh/known_hosts` ? Quell est exactement la commande `ssh-keygen` que vous devez lancer ? avec quel utilisateur ? > [@checkout](#): > > Etant donné que les machines sont remplacées régulièrement, est il possible de se passer de cette manipulation ? A en croire cet extrait de `man ssh` ce n’est pas vraiment évident ```auto /etc/ssh/ssh_known_hosts Systemwide list of known host keys. This file should be prepared by the system administrator to contain the public host keys of all machines in the organization. It should be world-readable. See sshd(8) for further details of the format of this file. ``` Semble dire que c’est votre affaire car vous avez été promu `system administrator` félicitations! 😄 Voici comment je procède si besoin est, je charge mes clés dans `ssh-agent` ```auto ssh-add -l ``` doit me retourner mes clés publiques. Puis je fais ```auto sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK bash root@debpacha:~# id uid=0(root) gid=0(root) groupes=0(root) root@debpacha:~# ``` et la commande `ssh-add -l` donne les mêmes clés publiques que celles de l’utilisateur initial. Je force la création du répertoire `/root/.ssh` avec les bons droits avec ```auto root@debpacha:/home/fp2# ssh localhost id uid=0(root) gid=0(root) groupes=0(root) ``` éventuellement j’accepte l’insertion dans /root/.ssh/known\_hosts Je copie mes clés publiques dans le fichier /root/.ssh/authorized\_keys ```auto p2@debpacha:~$ sudo ls -l /root/.ssh total 8 -rw-r--r-- 1 root root 246 janv. 31 01:33 authorized_keys -rw-r--r-- 1 root root 664 janv. 31 01:36 known_hosts fp2@debpacha:~$ ``` Lisez attentivement les lignes suivantes ```auto fp2@debpacha:~$ sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK id uid=0(root) gid=0(root) groupes=0(root) fp2@debpacha:~$ sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh localhost id uid=0(root) gid=0(root) groupes=0(root) fp2@debpacha:~$ ``` Vous obtenez la possibilité de lancer une commande d’administration sur toutes les machines que vous aurez configurées en copiant le fichier `/root/.ssh/authorized_keys` la commande étant ```auto sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK ssh machine commande params ``` et en plus vous n’avez pas de phrase de passe à taper. Cordialement, Regards, Mit freundlichen Grüßen, مع تحياتي الخالصة * * * F. Petitjean Ingénieur civil du Génie Maritime. « L’amour, c’est comme les spaghettis, quand c’est mou, c’est cuit. » Proverbe belge ---
**Author:** ![checkout](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/8edcca/32.png) [@checkout](https://www.debian-fr.org/u/checkout)\ **Post date:** [Juillet 20, 2018, 6:55 UTC](https://www.debian-fr.org/t/cle-ssh-renouvellement-de-parc/77240/4 "2018-07-20T06:55:35Z")
> [@Almtesh](#): > > Attends, je ne comprend pas ce que tu fais, tu changes la machine, et après, tu fais quoi avec ssh-keygen ? Je change la machine ou je la formate, de ce fait elle change d’ID je suppose et le serveur ne veut plus s’y connecter car il ne reconnait pas la machine. Donc je fais un ssh-keygen et c’est reparti mais ca ne m’arrange pas. ---
**Author:** ![checkout](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/8edcca/32.png) [@checkout](https://www.debian-fr.org/u/checkout)\ **Post date:** [Juillet 20, 2018, 7:02 UTC](https://www.debian-fr.org/t/cle-ssh-renouvellement-de-parc/77240/5 "2018-07-20T07:02:20Z")
> [@littlejohn75](#): > > Comment sont gérés les utilisateurs des machines du parc ? En particulier quels sont les identifiants sur le serveur central et sur la machine qui exécute le script ? > > Est-ce que les répertoires utilisateurs (HOME avec uid \>= 1000 ) sont partagés sur un serveur NFS par exemple ? > > Est-ce que les utilisateurs qui exécutent les scripts sont des utilisateurs systèmes (uid \< 1000 )? Non il n’y a aucun partage NFS, la procédure est simple mais pas très propre: Le script se connecte en ssh sur la machine distante avec un compte utilisateur lambda, une fois fait, elle lance une série de commandes bash et se déconnecte. > [@littlejohn75](#): > > copie de quelle clé publique ? > > Cette non reconnaissance d’une nouvelle machine est-elle due au fait que la commande ssh ne retrouve pas le nouveau nom et la nouvelle IP dans un fichier ~/.ssh/known\_hosts ? > > Quell est exactement la commande ssh-keygen que vous devez lancer ? avec quel utilisateur ? C’est exactement cela, la machine dans le ~/.ssh/known\_hosts n’est plus la même du coup j’ai une alerte. Du coup c’est le user1 du serveur qui relance un ssh-keygen pour pouvoir rafraichir le known host. Ca ressemble à ssh\_keygen -R 1XX.XX.XX.XXX ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Juillet 20, 2018, 7:18 UTC](https://www.debian-fr.org/t/cle-ssh-renouvellement-de-parc/77240/6 "2018-07-20T07:18:12Z")
C’est normal de devoir supprimer la signature de l’ancienne machine de ton fichier known\_hosts sur ton serveur, tu ne peux pas y couper, c’est le principe de protection par signature: si la signature a changé, c’est qu’il y a un loup. Tu es obligé de faire le ssh-keygen -R pour enlever la signature de la vieille machine du fichier, tu n’as pas vraaiment le choix de faire autrement. ---
**Author:** ![checkout](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/8edcca/32.png) [@checkout](https://www.debian-fr.org/u/checkout)\ **Post date:** [Juillet 20, 2018, 7:36 UTC](https://www.debian-fr.org/t/cle-ssh-renouvellement-de-parc/77240/7 "2018-07-20T07:36:57Z")
> [@mattotop](#): > > C’est normal de devoir supprimer la signature de l’ancienne machine de ton fichier known\_hosts sur ton serveur, tu ne peux pas y couper, c’est le principe de protection par signature: si la signature a changé, c’est qu’il y a un loup. > > Tu es obligé de faire le ssh-keygen -R pour enlever la signature de la vieille machine du fichier, tu n’as pas vraaiment le choix de faire autrement. Je pense que j’espérais une solution miracle effectivement. Je vais donc continuer de cette manière. Du coup pour éviter de faire la manipulation manuellement à chaque changement, puis je dans le script ajouter un ssh-keygen sur toute ma plage IP qui s’exécutera à chaque fois ? Est ce que cela aura des conséquences ? ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Juillet 20, 2018, 9:04 UTC](https://www.debian-fr.org/t/cle-ssh-renouvellement-de-parc/77240/8 "2018-07-20T09:04:51Z")
Ben faire ça aura pour conséquence que tu devras revalider les certificats de chacune de tes machines de ta frange ip. Aprés, je ne sais pas de quel script tu parles, donc bon.