en passant à l'algo de chiffrement ED25519 :
ssh-keygen -t ed25519
Ensuite, c'est la même utilisation que les clés RSA.
en passant à l'algo de chiffrement ED25519 :
ssh-keygen -t ed25519
Ensuite, c'est la même utilisation que les clés RSA.
Il faut d'abord savoir quelle machine va lancer la sauvegarde. Pour s'affranchir du problème des droits, c'est la machine qui sera sauvegardée qui lancera le backup. Elle sera appelé serveur par la suite et la machine recevant le backup sera appelé client.
Il faut donc installer le paquet openssh-server sur le serveur.
apt-get update
apt-get install openssh-server
On génère une paire de clé sur cette machine (celle qui va se connecter en ssh) avec l'utilsateur qui lancera la sauvegarde (dans mon cas, ce sera l'utilisateur root qui la lancera par une tâche cron) :
ssh-keygen -t ed25519
Un petit temps s'écoule.
On répond (par défaut ou pas) à la question sur le nom du fichier.
On a ensuite la question de la passphrase. Comme on veut se connecter sans mot de passe, on ne répond rien (on tape sur Entrée). On confirme. Et voilà, la clé ED25519 est créée.
Où ça ? C'est écrit :
Your identification has been saved in id_ed25519.
Your public key has been saved in /home/papadakis/.ssh/id_ed25519.
Là où vous l'avez mis, puisque vous n'avez pas mis de chemin lors de la question du fichier !
On copie la clé publique sur l'hôte client :
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 1234 login@client.net
Il suffit de suivre les conseils pour vérifier que tout s'est bien déroulé :
Now try logging into the machine, with "ssh -p '1234' 'login@serveur.net'", and check to make sure that only the key(s) you wanted were added.
On peut maintenant configurer une tâche cron qui ne réclamera pas de mot de passe.
Lorsqu'on réinstalle, les clés ssh n'aiment pas ça.
Et comme le fichier known_hosts est hashé, difficile de retrouver sa petite ligne.
Alors un simple
ssh-keygen -R nom_du_serveur
et ça va mieux !