2 votes

SSH sans mot de passe doit-il empêcher rsync d'un dossier avec des droits de lecture ?

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 ~]#

0voto

ndasusers Points 427

Désolé d'avoir dérangé tout le monde.

Pour exclure toute idée de clé ssh, j'ai créé une clé de mot de passe pour la sauvegarde et elle a également échoué. J'en ai donc conclu que ce n'était pas lié et que cela devait être basé sur les permissions dans /srv. Je ne suis pas l'administrateur là-bas, donc j'ai confié le problème à l'échelon supérieur pour attendre une réponse.

Et il s'avère que le répertoire /home/srv n'a pas reçu les mêmes permissions que le repo.

ls / -l
drwx---r-x  10 srv          srv          4096 Nov 15 16:08 srv

Donc, pour une raison quelconque, le groupe srv n'a pas eu accès à son propre dossier. LOL. Cela empêchait la sauvegarde d'entrer dans le dossier et bloquait l'accès, alors que user_2 pouvait lire, n'étant pas dans le groupe srv.

Encore toutes mes excuses pour ce billet frivole. Je ne fais que coller la réponse ici, pour la cacher de la file d'attente des tickets sans réponse.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X