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 ?
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 )?
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 ?
A en croire cet extrait de man ssh ce n’est pas vraiment évident
/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
ssh-add -l
doit me retourner mes clés publiques.
Puis je fais
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
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
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
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.
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.
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
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 ?
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.
