Tentando configurar o chroot'd rsync


10

Estou tentando configurar um servidor de backup. Desejo fazer chroot de cada usuário (cliente) em seu diretório pessoal e permitir apenas que ele use sftp e rsync .

Descobri rapidamente que não era o único a tentar fazer algo assim, encontrei este guia e o segui. Então agora eu tenho usuários chroot'd apenas com sftp.

Então eu descobri que o rsync precisa do ssh para aparecer na outra máquina, e que o sftp não é suficiente. Dar a cada usuário um login ssh é algo que eu queria evitar em primeiro lugar.

Alguém pode pensar em algumas soluções possíveis?

Obrigado,

Marca


Ter um olhar para esta resposta eu escrevi algum tempo ir serverfault.com/questions/255084/...
user9517

Respostas:


11

Uma solução sftp também exigiria um login ssh para todos, para que você realmente não tenha perdido nada aqui. A concessão de acesso ssh não implica necessariamente acesso total ao shell; por exemplo, isso mostra como usar o authorized_keysarquivo ssh para permitir backup via rsync, limitando os comandos disponíveis apenas ao receptor rsync.

De fato, se você optar pela autenticação baseada em chave, em vez da autenticação por senha (o que você deve), poderá executar tudo em uma conta de usuário em vez de exigir várias contas. Você usaria chaves para identificar usuários remotos e direcionar o receptor rsync para um diretório específico.

Algo assim, no seu authorized_keysarquivo:

command="/usr/bin/rsync --server -a . /tmp/user1" ssh-rsa ... user1
command="/usr/bin/rsync --server -a . /tmp/user2" ssh-rsa ... user2

Alguém usando a user1chave privada fará backup /tmp/user1e alguém usando a user2chave privada fará backup /tmp/user2. E assim por diante...


O link se foi 404.
luckydonald 28/03

Eu atualizei o link.
Larsks 28/03/19

6

Execute o habitual rsyncdo cliente para o servidor remoto, mas adicione uma opção detalhada adicional:, SSH -ve depois grep for Sending command. Você verá o comando exato que o cliente está enviando para o servidor remoto:

rsync -avz -e'ssh -v -i /ssh-keys/clientprivate.key' --bwlimit=8000 --delete root@server:/path/ /backup/myserver/ 2>&1 | grep "Sending command"

No meu caso, foi

rsync --server -vvlogDtprze.iLsf --bwlimit=8000 --delete . /path

Adicione isso command="..."ao /home/USER/.ssh/authorized_keysarquivo do servidor remoto como @larsks mencionado. Adicione configurações adicionais de segurança, se necessário:

no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2..CPhIJ+LVULWz arnis@server

Todos juntos:

command="rsync --server -vvlogDtprze.iLsf --bwlimit=8000 --delete . /backup/path",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2..CPhIJ+LVULWz arnis@server

(Extraído do muito bom tutorial http://en.positon.org/post/Rsync-command-restriction-over-SSH )


Boa 1ª resposta.
Slm

2

Você precisará fornecer alguma forma de acesso ao shell para poder usar o rsync, a menos que esteja se conectando diretamente ao servidor rsync - a porta padrão é 873 (TCP).

Na página do manual rysnc :

Há duas maneiras diferentes de o rsync entrar em contato com um sistema remoto: usar um programa de shell remoto como o transporte (como ssh ou rsh) ou entrar em contato com um daemon do rsync diretamente via TCP. O transporte de shell remoto é usado sempre que o caminho de origem ou destino contiver um único separador de dois pontos (:) após uma especificação de host. O contato com um daemon rsync acontece diretamente quando o caminho de origem ou destino contém um separador de dois pontos (: :) após uma especificação de host, OU quando uma URL rsync: // é especificada (consulte também o lqUSING RSYNC-DAEMON RECURSOS ATRAVÉS DE UM REMOTE-SHELL CONNECTIONrq para uma exceção a esta última regra).

Para fornecer acesso limitado ao shell, considere o seguinte guia . (Nota: o link original está inoperante)

Essa configuração combina os melhores recursos de rsync, SSH e chroot. O Rsync oferece flexibilidade e eficiência na transferência de arquivos, o SSH protege os dados que estão sendo transferidos e o chroot protege os dados no servidor contra acesso não autorizado. O dummysh limita o acesso apenas ao rsync.

Enquanto o servidor rsync implementa o chroot, ele não possui a proteção SSH que geralmente é necessária. Além disso, a abertura de uma porta adicional do servidor rsync apresenta um risco à segurança e, às vezes, não é possível técnica ou politicamente. Sftp e scp não têm a flexibilidade e a eficiência fornecidas pelo rsync, especialmente quando uma árvore de diretórios está envolvida, como um site.

Ou dê uma olhada no rssh (há um guia para configurar o rssh aqui ):

rssh é um shell restrito para uso com o OpenSSH, permitindo apenas scp e / ou sftp. Agora também inclui suporte para rdist, rsync e cvs. Por exemplo, se você possui um servidor no qual deseja permitir que os usuários copiem arquivos via scp, sem fornecer acesso ao shell, é possível usar o rssh para fazer isso.


1
A notícia atual é que o rssh não está sendo mantido e tem algumas falhas de segurança estranhas. Verifique novamente o estado atual antes de investir nele.
Chutz 19/05/12

2
Você pode usar o script perl em rrsyncvez do rssh, incluído no pacote oficial do rsync. Veja derek.simkowiak.net/backing-up-multiple-servers-with-rsnapshot
unhammer

0

você pode escrever um shell que envolve o rsync.

veja a ideia geral aqui: https://sixohthree.com/1458/locking-down-rsync-using-ssh

no seu invólucro, você pode fazer o que quiser e talvez chroot o usuário.

No meu caso, eu precisava ativar a conta virtual usando o mesmo usuário * nix. Consigo fazer isso usando esse tipo de shell, além de muitas linhas no arquivo allowed_keys. Eu não fiz o chroot do usuário, mas adicionei um nível de pasta do usuário no comando rsync server.

veja o usuário do processo de maneira diferente usando a tecla ssh


0

SFTP com recursos Rsync, sem shell

Você pode usar LFTP + SFTP em um ambiente chroot e obter os mesmos resultados que o rsync, sem fornecer ao usuário um shell ou fazer personalizações pesadas no ssh com wrappers.

Isso é mais seguro e pode ser substancialmente mais rápido.


Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.