O SSH sem senha deve impedir o rsync de uma pasta com permissão de leitura?

2

Desculpe pela longa pergunta. Eu tento adicionar tantos detalhes quanto eu tenho.

No server_1, eu tenho um usuário de conta de sistema chamado backup que possui um diretório inicial no qual as tarefas cron lêem os scripts de backup.

backup@server_1~]$ ls 
script_1    script_2 ...

No servidor_2, criei um usuário padrão "backup" para manter alguns repositórios que estão atualmente em backup no servidor_1. Aqueles suportados multa por meses. Agora, eu adicionei um link para um novo repo em / srv que é de propriedade do usuário & group 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.

Em seguida, adicionei o backup no server_2 ao grupo srv, para que o backup possa ler todos os dados para uma sincronização no server_1.

root@server_2~]# usermod -a -G srv backup

Então eu tentei rsync:

backup@server_1~]$ rsync -avi -e "ssh -i /home/backup/.ssh/server_2_ssh_key" \
                   backup@server_2/srv/repo_3 ./

O problema é que, quando executo o script de backup, usando o login sem senha do server_1, ele falha ao ler os dados, porque o rsync não pode mudar para o diretório / srv / repo_3 devido à "permissão negada". tentou usar o link simbólico.

backup@server_1~]$ rsync -avi -e "ssh -i /home/backup/.ssh/server_2_ssh_key" \
                   backup@server_2/home/backup/repo_3 ./

Então, eu até me conectei usando o par de chaves de backup para server_1 e não consigo nem mesmo listar o conteúdo de / srv / repo_3

Por acaso tenho outra conta de usuário padrão no server_2 que usa um Login de chave SSH com uma senha. Quando eu faço o login dessa maneira, "user_2" é capaz de listar o conteúdo de / srv

Então, copiei a chave ssh dos segundos usuários do server_2 para /home/backup/.ssh/ssh_key_w_password no server_1 e adicionei a parte pública aos hosts confiáveis do backup no server_2. Então eu tentei o backup usando essa chave.

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: 

Eu digitei a senha e o backup foi executado corretamente, mesmo que o user_2 não esteja nem no backup ou no grupo srv no server_2. Ele funciona pelo symlink ou pela localização direta / srv / repo_3.

Alguns detalhes do usuário:

 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

Lá estamos nós. A única diferença que posso encontrar do meu lado é que o backup usa um par de chaves sem senha do server_1, enquanto o outro usuário padrão tem a senha na chave SSH.

Alguém pode me ajudar a entender o que é diferente ou o que estou perdendo? Eu devo ter backup no server_1 usar o login sem palavras para executar a sincronização. Eu não posso permitir server_2 para sincronizar até server_1.

Atualização: re: comentário de MadHatter O login direto falha como backup do servidor1 porque o login baseado em senha não é permitido. Mas o uso da chave sem senha retorna a saída (assim como a mesma tentativa com a chave de senha do outro usuário.

[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 ~]$ 

Para referência, estas são as mensagens de log de falha do rsync quando eu tentei novamente usando o login sem senha como root no server_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 ~]#
    
por ndasusers 18.11.2013 / 03:24

1 resposta

0

Desculpe ter incomodado a todos.

Para excluir qualquer ideia de chave ssh, criei uma chave de senha para backup e ela também falhou. Então, eu concluí que não estava relacionado e deve ser baseado nas permissões em / srv. Eu não sou o administrador lá, então eu confiro na escada para esperar pela resposta.

E, acontece que o diretório / home / srv não recebeu as mesmas permissões que o repositório.

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

Portanto, por algum motivo, o grupo srv não recebeu acesso à sua própria pasta. RI MUITO. Isso impedia que o backup entrasse na pasta e bloqueasse o acesso, enquanto o user_2 podia ler, não estando no grupo de srv.

Desculpa novamente por este bilhete frívolo. Eu só colo a resposta aqui, para escondê-lo da fila não atendida.

    
por 18.11.2013 / 21:01