Bonjour à tous,
Voilà, il m’arrive quelque chose que je ne m’explique en aucune façon.
Après la disparition dans les flammes strasbourgeoises du serveur de notre association, je souscris à une nouvelle offre de serveur dédié, toujours chez OVH, mais dans un datacenter situé à Varsovie, cette fois.
C’est l’occasion de changer de système et j’abandonne Centos7 pour Debian10. Je recrée tous les services dont nous avons besoin (Kolab Groupware et Nextcloud derrière nginx pour l’essentiel), puis, armé de patience, car les sauvegardes se trouvent à mon domicile en zone plutôt blanche, je remonte toutes les données importantes, e-mails et fichiers divers, sur le nouveau serveur. Tout fonctionne impeccablement : je souffle ; l’association aussi.
Une dernière chose à faire : remettre en place le script de sauvegarde. C’est tout bête, un peu de rsync dans beaucoup de python, et ça fonctionne très bien.
Je remets donc le script en place et, étourdiment, le lance sans avoir au préalable généré de clef ssh pour le compte root du serveur Debian ni, donc, l’avoir exportée sur le serveur présent à mon domicile. Peste, me dis-je, ça va planter, et je vais pour stopper la chose d’un ctrl+c bien ajusté quand je découvre avec effarement que le script tourne sans souci. Autrement dit, rsync s’est connecté sans clef d’aucune sorte à mon compte de sauvegarde.
Un peu ébahi, j’ouvre une seconde connexion au serveur OVH et je tente un accès direct par ssh à mon domicile : idem. Connexion réussie. Je vérifie : pas de clef ssh générée sur le serveur debian (le dossier .ssh est vide à l’exception du fichier known_hosts). Je vérifie également le fichier authorized_keys de mon serveur de sauvegarde : en dehors de la clef de l’ancien serveur Centos7 défunt, il n’y a rien.
Le problème viendrait-il de mon serveur de sauvegarde ou du compte utilisé sur celui-ci ? Que nenni : aucune autre tentative d’accéder à ce compte via ssh sans mot de passe ou sans clef n’est couronnée de succès.
Donc, je ne comprends pas. Mais alors pas du tout.
Auriez-vous la bonté de me donner vos avis ?
Ah, ultime détail piquant : l’accès fonctionne depuis la console (soit par la commande ssh, soi en exécutant le script), mais pas depuis crontab, les logs montrant alors que la « clef » (je me demande bien laquelle) est refusée…
# verbose
Posté par cg . Évalué à 4.
Joli mystère :).
essaye avec
ssh -v
qui va te dire des trucs du genre:Au hasard, y-a-t-il un
/root/.ssh/config
ou/etc/ssh/ssh_config
qui indique une clé spécifique pour se connecter sur ton serveur de sauvegarde ? Fichier qui aurait été restauré depuis ton backup.(et bravo d'avoir des backups offline !)
[^] # Re: verbose
Posté par Marc Quinton . Évalué à 2.
tu peux essayer avec
ssh ... -o IdentitiesOnly=yes
pour voir ?[^] # Re: verbose
Posté par SebastienWeber . Évalué à 4.
Bingo !
Un fichier /etc/ssh/ssh_config hâtivement restauré, lequel pointe, en effet, une clef située dans un répertoire lui-même restauré…
Merci ! Ça me retire une méchante turlupinette de la tête et ça m’apprendra à bourriner les restaurations quand Varsovie partira en fumée (ce qu’à Dieu ne plaise !)
ssh -v… Je me la noter dans un petit pense-bête, celle-là…
Merci !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.