sauvegarde distante avec Grsync

azrael_79 · Le 24/02/2024, à 20:05

Bonjour,

Je souhaite réaliser une sauvegarde sur une machine distante de mon réseau local via Grsync.

J'ai systématiquement une erreur d'authentification "Host key verification failed" lorsque j'entre dans Grsync le chemin de la machine cible...

J'ai épluché la documentation SSH et pense être parvenu à créer une clé privée + clé publique. J'ai copié la clé publique sur la machine cible. Et maintenant, je ne sais plus quoi faire...

Une bonne âme pourrait-elle m'aider SVP ??

Merci !!

Dernière modification par azrael_79 (Le 25/02/2024, à 11:29)

Vobul · Le 25/02/2024, à 12:47

Parviens-tu à faire "ssh machine-cible" ?

Alors ça me déprime de devoir le préciser mais : dans la commande ci-dessus, remplace "machine-cible" par le nom ou l'ip de ta machine cible....

azrael_79 · Le 25/02/2024, à 19:46

Bonjour Vobul, merci pour ta réponse !

Désolé mais j'ai oublié de préciser au premier post que la connexion SSH avec la cible fonctionne bien, via un terminal ou l'explorateur de fichier. Je peux voir et modifier le contenu du home distant de cette façon.

Lorsque j'essaie de lancer une synchronisation via Grsync (ou LuckyBackup), ça ne fonctionne pas.

J'ai coché dans Grsync "Exécuter en mode administrateur", qui me demande alors le mot de passe admin si je démarre une opération, mais la "clé de vérification" n'est pas reconnue. D'ailleurs, je ne sais pas exactement de quelle clé il est question...

Je réalisais jusqu'à présent des sauvegardes distantes avec LuckyBackup, qui demandait simplement le mot de passe admin pour démarrer l'opération. Suite à réinstallation des OS sur les machines, je n'y arrive plus et j'ai ce message : "Host key verification"

Je ne suis pas très familier de ces questions de clés de chiffrements, publiques et privées, même après lecture attentive de la rubrique concernée dans la documentation SSH. J'ai l'impression que je rencontre pourtant un problème de ce type.

Qu'en penses-tu ?

Merci !

Vobul · Le 25/02/2024, à 20:45

En gros quand tu te connectes à un serveur pour la première fois, ssh te demande si la clé du "Host" (le serveur) est bonne. Il t'affiche le fingerprint, tu dis oui, puis il stocke ça dans ~/.ssh/known_hosts (va voir son contenu !). Sauf que si tu démarres le logiciel de backup avec l'utilisateur root, lui n'a pas accepté ce fingerprint (la Host key), et ça foire.

Le plus simple est de ssh sur la machine avec l'utilisateur root une fois, comme ça t'acceptes le Host key et ça devrait être bon après.

Le mieux est de lancer le logiciel de backup en tant qu'utilisateur. Normalement ton utilisateur a accès à toutes les données potentiellement à sauvegarder.

azrael_79 · Le 26/02/2024, à 11:47

Merci pour ces explications.

Je prends note qu'il n'est pas utile de faire ses sauvegardes en root.

J'ai lancé un sudo ssh dans le terminal de la machine où j'exécute Grsync.

Il m'a posé 3 questions que j'ai malheureusement oubliées. Et avec la fatigue, je n'ai pas pris la peine de capturer les questions. En gros, j'avais 3 choix : forcer la connexion par "Yes", refuser la connexion par "No", modification l'empreinte de la clé existante. J'ai choisis "Yes" et constaté après que le fichier known_hosts du dossier SSH de root avait changé.

Mais quand j'essaie de relancer une sauvegarde via Grsync ou LuckyBackup, c'est toujours le même message : "Permission denied (publickey,password)."

Avec une évolution cependant dans LuckyBackup : quand je lui demande d'utiliser le known_hosts du SSH de la machine cible, il ajoute : "/.ssh/known_hosts": error in libcrypto"

N'y a t-il pas possibilité de supprimer toutes les clés connues sur les 2 machines pour repartir de zéro ?

Merci

Vobul · Le 26/02/2024, à 13:59

Tu vois, tu progresses. Maintenant le soucis c'est que la clé SSH n'est pas présente dans /root/.ssh, donc il te refuse l'accès, et c'est bien normal. Il te faut copier la clé ssh elle-même dans /root/.ssh afin que cela fonctionne.

Normalement toutes ces aventures vont te permettre d'avoir une meilleur connaissance de ssh

azrael_79 · Le 26/02/2024, à 16:14

Merci pour tes explications !

Donc j'ai essayé de copier la clé SSH, mais je ne sais pas vraiment de quelle clé on parle... La clé privée ? Publique ? Faut-il copier le fichier known_hosts ? Je mélange tout. Je fini par ne plus savoir ce que je fais.

J'ai donc effacé manuellement tous les "known_hosts" que j'ai trouvés, ainsi que tous les fichiers de clés publiques et privées trouvés dans les SSH, en mode root et normal. Je souhaiterais recommencer de zéro, en effaçant avec certitude toutes ces données d'identification. Une commande le permet-elle ?

Quand je relance une sauvegarde, aucune évolution du côté de Grsync ou LuckyBackup, toujours les mêmes avertissements : "Permission denied, please try again. hp@xxx.xxx.x.xxx: Permission denied (publickey,password).

Un truc qui m'échappe encore + : avant la réinstallation des OS, je n'ai JAMAIS créé (en tout cas volontairement) et utilisé une quelconque clé de quoi que ce soit. Lorsque je lançais une sauvegarde distante via LuckyBackup, il me demandait juste le mot de passe du PC distant... ça fonctionnait parfaitement (peut-être de manière moins sécurisée alors ?)

Qu'est-ce qui a changé entre temps ??

Merci

O_20_100_O · Le 26/02/2024, à 16:45

mais je ne sais pas vraiment de quelle clé on parle... La clé privée ? Publique ?

A ce sujet, voilà un lien vers la documentation.
https://doc.ubuntu-fr.org/ssh#authentif … iqueprivee

azrael_79 · Le 26/02/2024, à 16:54

O_20_100_O a écrit :

A ce sujet, voilà un lien vers la documentation.
https://doc.ubuntu-fr.org/ssh#authentif … iqueprivee

Merci pour cette page, que j'ai déjà lue mais pas entièrement comprise... Je vais m'y replonger correctement dès que possible !

O_20_100_O · Le 26/02/2024, à 17:06

Dis-nous ce que tu ne comprends pas.

azrael_79 · Le 27/02/2024, à 11:38

Alors allons-y, 1ère question !

La documentation explique au début les notions de serveurs et clients :

SSH est un protocole permettant d'établir une communication chiffrée, donc sécurisée (on parle parfois de tunnel), sur un réseau informatique (intranet ou Internet) entre une machine locale (le client) et une machine distante (le serveur).

J'ai un PC principal (Kubuntu), qui contient les données sources que je souhaite sauvegarder sur un PC secondaire (Xubuntu). Les 2 PC sont connectés au routeur domestique. Je peux échanger des données entre ces 2 PC via leurs explorateurs de fichiers respectifs et SSH.

Ma question est : qui est le client et le serveur dans mon histoire ? Par définition, toutes les machines physiques sont distantes entre-elles, ça dépend d'où on se place...

Et oui, y'a du boulot avec moi

Merci !

O_20_100_O · Le 27/02/2024, à 12:45

la doc a écrit :

sur un réseau informatique (intranet ou Internet) entre une machine locale (le client) et une machine distante (le serveur).

On pourrait écrire :
entre plusieurs machines, locales ou distantes, dont au moins un serveur et des clients.
Le fait que la machine soit locale ou distante n'intervient que pour gérer les connexions en mode IPv4.

: qui est le client et le serveur dans mon histoire ? P

Le serveur, c'est la machine sur laquelle tourne openssh-server, mais une machine peut être à la fois client et serveur.
C'est comme dans la vrai vie, le serveur du bistro du coin est aussi client de la brasserie d'à côté.

Dans ton cas, si j'ai bien compris, le serveur est le PC à sauvegarder et le client celui sur lequel tu fais la sauvegarde. mais cela pourrait tout aussi bien être l'inverse.
Le client est celui qui demande avec openssh-client et le serveur celui qui répond avec openssh-server.

Dernière modification par O_20_100_O (Le 27/02/2024, à 13:56)

bruno · Le 27/02/2024, à 12:51

Merci j'ai corrigé le début la doc qui était inutilement complexe et contenait une erreur grossière.

Le serveur est la machine qui exécute le démon sshd (installé par le paquet openss-server) C'est lui qui est en écoute sur le port 22 en attente des connexions des ceints.
Le client est celui qui utilise une commande ssh (par exemple) pour se connecter au serveur ou y exécuter des commandes. Exemple :

ssh toto@serveur

Cette commande est installée par défaut sur Ubuntu avec le paquet openssh-client

Bien sûr une même machine peut être à la fois client et serveur.

azrael_79 · Le 27/02/2024, à 16:28

Merci à vous 2, j'y vois un peu plus clair sur cette notion clients-serveurs.

Analogie parfaite pour le comprendre :

O_20_100_O a écrit :

Le serveur, c'est la machine sur laquelle tourne openssh-server, mais une machine peut être à la fois client et serveur.
C'est comme dans la vrai vie, le serveur du bistro du coin est aussi client de la brasserie d'à côté.

Je vais reprendre la manip du début : essayer de générer puis copier les clés de chiffrement aux bons endroits !

azrael_79 · Le 28/02/2024, à 19:52

J'ai finalement compris ce qui bloquait l'authentification. Dans la documentation, il est précisé de passer la commande suivante une fois la paire de clés générée, puis la clé publique copiée sur la machine cible :

ssh-add

Je n'avais pas compris que cette commande devait être passée à chaque nouvelle session ou reboot de la machine, la clé SSH étant visiblement "inactive" par défaut au démarrage de l'OS ou d'une session. Voilà où était le problème...

J'ai encore du mal à distinguer serveurs et clients, notamment dans ce résumé de la documentation :

En résumé (car les paragraphes ci-dessous utilisant des scripts peuvent sembler confus à certains)
Coté client : Il faut que le client ait mis sa clé privée en $HOME/.ssh/ (côté client).
Coté client : la clé doit être connue de l'agent ssh (ssh-add)
Coté client : Le répertoire $HOME/.ssh doit appartenir au propriétaire de $HOME et les clés privées ne doivent être accessibles que par leur propriétaire (mode rw------ ou 600 au maximum)
Coté serveur : La clé publique du client doit se trouver dans le fichier $HOME/.ssh/authorized_keys du serveur.
Coté serveur : il vaut mieux refuser l'accès par mot de passe ("PasswordAuthentication no" dans /etc/ssh/sshd_config du serveur)

Quoi qu'il en soit, problème résolu pour moi !

Merci à tous pour votre aide

O_20_100_O · Le 28/02/2024, à 20:34

je n'avais pas compris que cette commande devait être passée à chaque nouvelle session

Non, ce n'est pas le cas.
Une autre façon d'expliquer les choses :
https://debian-facile.org/utilisateurs: … :tutos:scp

azrael_79 · Le 29/02/2024, à 15:50

Merci pour cette page de doc que j'ai lue attentivement. Il n'y est nulle part mentionné que

ssh-add

doit être passée à chaque démarrage.

Effectivement, lorsque j'essaie d'atteindre la machine distante via l'explorateur, c'est désormais la passphrase qui est demandée pour accéder aux fichiers distants.

Par contre, impossible de lancer une sauvegarde LuckyBackup sans avoir passé préalablement cette commande. J'ai essayé plusieurs fois.

LuckyBackup affiche alors :

"Permission denied, please try again.
Permission denied, please try again.
xxxx@xxx.xxx.x.xxx: Permission denied (publickey,password).

Avec la commande, tout fonctionne.

Ce n'est pas grave, faut juste y penser !

Vobul · Le 29/02/2024, à 16:08

ou créer une clé ssh sans mot de passe pour les backups...

Dernière modification par Vobul (Le 29/02/2024, à 16:08)

O_20_100_O · Le 29/02/2024, à 19:53

Oui, créer une clé ssh sans passphrase.

azrael_79 · Le 04/03/2024, à 10:56

Vobul a écrit :

ou créer une clé ssh sans mot de passe pour les backups...

Plusieurs paires de clés peuvent cohabiter sur les mêmes machines ?

Si je comprends bien, il peut exister :

- 1 paire de clé avec passphrase, pour échanger par exemple des fichiers entre A et B via l'explorateur
- 1 deuxième paire de clé, sans passphrase, qui permet d'exécuter des backups de A vers B

Dans ce dernier cas, comment la machine choisie la paire de clé adéquate, et demande ou non la passphrase ? N'est-ce pas gênant pour la sécurité ?

Merci

Vobul · Le 04/03/2024, à 15:57

Connectes-toi avec "ssh -vvv" pour avoir plein d'infos sur ce qu'il fait. Tu verras qu'il tente toutes les clés qu'il trouve, sauf si IdentityFile est définie dans ta config. Car oui, tu devrais te faire un .ssh/config pour faciliter les choses si ce n'est pas déjà fait.

> N'est-ce pas gênant pour la sécurité ?

Non, si un attaquant a accès à ta clé ssh il a sûrement également accès à toutes tes autres données, donc il n'en a rien à faire d'accéder à tes backups. Certes, c'est mieux de toujours avoir une passphrase sur ses clés ssh, mais là tu en es aux balbutiements de la compréhension de ce monde : par exemple, tu peux configurer ssh sur le serveur pour ne permettre que de faire du rsync sur le dossier de backup (cf. rrsync, oui avec deux r). Donc tu limites grandement l'impact d'une fuite de cette clé. Couple ça au whitelisting ip + firewall et t'es pas mal !

from="12.34.45.252" command="/usr/local/bin/rrsync ~/backups",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

Après y'a des trucs comme teleport où tu peux ajouter du 2FA avec clé physique. Enfin bref, la sécurité informatique est un vaste sujet. Pour ce qui te concernes, à savoir faire des sauvegardes auto de tes photos de vacance, une clé ssh simple sans chichi ira très bien !

azrael_79 · Hier à 09:33

Merci pour ces explications !

Pour la création d'un fichier config SSH, cette page semble intéressante...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 24/02/2024, à 20:05

sauvegarde distante avec Grsync

#2 Le 25/02/2024, à 12:47

Re : sauvegarde distante avec Grsync

#3 Le 25/02/2024, à 19:46

Re : sauvegarde distante avec Grsync

#4 Le 25/02/2024, à 20:45

Re : sauvegarde distante avec Grsync

#5 Le 26/02/2024, à 11:47

Re : sauvegarde distante avec Grsync

#6 Le 26/02/2024, à 13:59

Re : sauvegarde distante avec Grsync

#7 Le 26/02/2024, à 16:14

Re : sauvegarde distante avec Grsync

#8 Le 26/02/2024, à 16:45

Re : sauvegarde distante avec Grsync

#9 Le 26/02/2024, à 16:54

Re : sauvegarde distante avec Grsync

#10 Le 26/02/2024, à 17:06

Re : sauvegarde distante avec Grsync

#11 Le 27/02/2024, à 11:38

Re : sauvegarde distante avec Grsync

#12 Le 27/02/2024, à 12:45

Re : sauvegarde distante avec Grsync

#13 Le 27/02/2024, à 12:51

Re : sauvegarde distante avec Grsync

#14 Le 27/02/2024, à 16:28

Re : sauvegarde distante avec Grsync

#15 Le 28/02/2024, à 19:52

Re : sauvegarde distante avec Grsync

#16 Le 28/02/2024, à 20:34

Re : sauvegarde distante avec Grsync

#17 Le 29/02/2024, à 15:50

Re : sauvegarde distante avec Grsync

#18 Le 29/02/2024, à 16:08

Re : sauvegarde distante avec Grsync

#19 Le 29/02/2024, à 19:53

Re : sauvegarde distante avec Grsync

#20 Le 04/03/2024, à 10:56

Re : sauvegarde distante avec Grsync

#21 Le 04/03/2024, à 15:57

Re : sauvegarde distante avec Grsync

#22 Hier à 09:33

Re : sauvegarde distante avec Grsync

Pied de page des forums