Désolé pour cette longue question. J'essaie d'ajouter autant de détails que possible.
Sur le serveur_1, j'ai un utilisateur de compte système nommé backup qui a un répertoire personnel où les tâches cron lisent les scripts de backup.
backup@server_1~]$ ls
script_1 script_2 ...
Sur le serveur_2, j'ai créé un utilisateur standard "backup" pour contenir certains référentiels qui sont actuellement sauvegardés sur le serveur_1. Ceux-ci ont été sauvegardés sans problème pendant des mois. Maintenant, j'ai ajouté un lien vers un nouveau dépôt dans /srv qui appartient à l'utilisateur et au groupe srv.
backup@server_2~]$ ls
drwxrwxr.. backup:backup repo_1
drwxrwxr.. backup:backup repo_2
lrwxrwx... backup:backup repo_3 -> /srv/repo_3
backup@server_2~]$ ls /srv
drwxrwxr.. srv:srv repo_3
^ notice the r, indicating any user should be able to read this data too.
J'ai ensuite ajouté la sauvegarde sur le serveur_2 dans le groupe srv, afin que la sauvegarde puisse lire toutes les données pour une synchronisation sur le serveur_1.
root@server_2~]# usermod -a -G srv backup
Puis j'ai essayé de rsynchroniser :
backup@server_1~]$ rsync -avi -e "ssh -i /home/backup/.ssh/server_2_ssh_key" \
backup@server_2/srv/repo_3 ./
Le problème est que, lorsque j'exécute la sauvegarde script, en utilisant le login sans mot de passe du serveur_1, il échoue à lire les données, car rsync est incapable de passer au répertoire /srv/repo_3 en raison de "permission denied" La même chose se produit lorsque j'ai essayé d'utiliser le lien symbolique.
backup@server_1~]$ rsync -avi -e "ssh -i /home/backup/.ssh/server_2_ssh_key" \
backup@server_2/home/backup/repo_3 ./
Ensuite, j'ai même ouvert une session en utilisant la paire de clés de sauvegarde des utilisateurs sur le serveur_1 et je suis incapable de lister le contenu de /srv/repo_3.
Il se trouve que j'ai un autre compte utilisateur standard sur le serveur_2 qui utilise une clé SSH de connexion avec un mot de passe. Lorsque je me connecte de cette manière, "user_2" est capable de lister le contenu de /srv.
J'ai donc copié la clé ssh du deuxième utilisateur du serveur_2 dans /home/backup/.ssh/ssh_key_w_password sur le serveur_1, et j'ai ajouté la partie publique aux hôtes de confiance de la sauvegarde sur le serveur_2. J'ai ensuite essayé la sauvegarde en utilisant cette clé.
backup@server_1~]$ rsync -avi -e "ssh -i /home/backup/.ssh/ssh_key_w_password" \
backup@server_2/home/backup/repo_3 ./
Password for ssh_key_w_password:
J'ai entré le mot de passe et la sauvegarde s'est exécutée correctement, bien que l'utilisateur_2 ne soit même pas dans le groupe backup ou srv sur le serveur_2. Cela fonctionne par le lien symbolique ou par l'emplacement direct /srv/repo_3.
Quelques détails sur l'utilisateur :
backup@server_2~]$ cat /etc/passwd | grep backup
backup:x:1008:1008:backup:/home/backup:/bin/bash
backup@server_2~]$ groups
backup srv
user_2@server_2~]# cat /etc/passwd | grep user_2
user_2:x:1012:1012:user_2:/home/user_2:/bin/bash
root@server_2~]# groups user_2
user_2
user_2@server_2~]$ cat /etc/passwd | grep srv
srv:x:1018:1021::/home/srv:/bin/bash
user_2@server_2~]$ groups srv
srv : srv mycorp 4h jndj ax
Nous y sommes. La seule différence que je peux trouver de mon côté est que la sauvegarde utilise une paire de clés sans mot de passe du serveur_1, alors que l'autre utilisateur standard a le mot de passe sur la clé SSH.
Quelqu'un peut-il m'aider à comprendre ce qui est différent ou ce qui me manque ? Je dois avoir la sauvegarde sur le serveur_1 utiliser la connexion sans mot de passe pour exécuter la synchronisation. Je ne peux pas autoriser le serveur_2 à se synchroniser avec le serveur_1.
Mise à jour : re : commentaire de MadHatter La connexion directe échoue en tant que sauvegarde à partir du serveur 1 car la connexion par mot de passe n'est pas autorisée. Mais l'utilisation de la clé sans mot de passe renvoie un résultat (tout comme la même tentative avec la clé avec mot de passe de l'autre utilisateur.
[backup@server_1 ~]$ ssh backup@server_2 "id -a"
backup@server_2's password:
Permission denied, please try again.
[backup@server_1 ~]$ ssh -i .ssh/backup_server_2_ssh.key backup@server_2 "id -a"
uid=1008(backup) gid=1008(backup) groups=1008(backup),1021(srv)
[backup@server_1 ~]$
[backup@server_1 ~]$ ssh -i .ssh/ssh_key_w_password user_2@server_2 "id -a"
Enter passphrase for key '.ssh/ssh_key_w_password':
uid=1012(user_2) gid=1012(user_2) groups=1012(user_2)
[backup@server_1 ~]$
Pour référence, voici les messages d'échec de rsync lorsque j'ai réessayé en utilisant la connexion sans mot de passe en tant que root sur le serveur_1.
[root@server_1 ~]# bash /home/backup/add_srv.sh
2013-11-18 12:24:14 - ************ Backup Robot Checking In **********
.... login and mount backup destination goes ok here rsync fail is below ....
2013/11/18 12:24:20 [920] receiving file list
2013/11/18 12:24:20 [920] rsync: change_dir "/srv" failed: Permission denied (13)
2013/11/18 12:24:20 [920] sent 8 bytes received 10 bytes 12.00 bytes/sec
2013/11/18 12:24:20 [920] total size is 0 speedup is 0.00
2013/11/18 12:24:20 [920] rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1505) [receiver=3.0.6]
[root@server_1 ~]#