Permissões através de root com SSH

Bom dia, boa tarde, boa noite!!!

Pessoal estou com um problema da seguinte forma:
Estou fazendo um rsync entre 2 servers (Ubuntu Server) através do SSH, eu quero que este sync seja realizado entre os 2 servers nos mesmo diretórios, exemplo:
DE: server1 /etc/diretorio1
PARA: server2 /etc/diretorio1
Acontece que este diretórios apenas root tem permissão de escrita e execução e quero manter desta forma.
No servidor que vai enviar os arquivo eu passo o parâmetro: sudo rsync -avh /etc/diretorio1 user@server2:/etc/diretorio1 , mas isso gera erro de permissão para gravar no destino.
Temporariamente estou usando um diretório de transição com permissoes para o meu usuário conseguir fazer como no exemplo:
sudo rsync -avh /etc/diretorio1 user@server2:/home/user/diretorio2
Neste caso depois no server2 executo outra vez o rsync:
sudo rsync -avh /home/user/diretorio2 /etc/diretorio1

Gostaria do apoio de vocês para encontrar uma forma de enviar diretamente mantendo a segurança, eu fiz um teste ativando o usuário root e permitindo ele no ssh, porém aumenta bastante o risco.
Eu tentei também colocar o usuário user com permissão de gravação no diretório1, porém nos mesmo testes não deu certo.

Desde já agradeço ajuda de todos.

Comecei a fazer backups com rsync e rclone há pouco tempo, mas deixo aqui meus 10 centavos.

Se você não quer alterar as permissões dos diretórios, de uma forma ou de outra terá que escalar privilégios no Server2, certo? Acho que não tem fuga diante do que você tem dito.

Não sei sobre as boas práticas envolvidas do que vou recomendar: acessar o usuário root por SSH, direto no rsync (em vez de user@servidor, root@servidor), não seria uma opção viável, acessando por chaves?

Espero que tenha ajudado a abstrair algo, ao menos.

1 curtida

Talvez a solução não seja por usuário root (id zero), mas sim criar um usuário específico e habilitar permissões somente para o que precisa ser feito. Se os arquivos são de um servidor, use as permissões de um usuário “server” que já deve existir. Se é para um script de monitoramento, crie um usuário “monitor” e dê a ele apenas as permissões para o monitoramento.

1 curtida

O que eu já fiz aqui foi isso, eu crei um usuario somente para fazer essa rotina e atribui ele a todos os grupos que estão os diretórios, por exemplo, grupo root, docker e alguns outros, porem ainda estou tendo problema de permissão em subgrupos.

Então eu cheguei testar com o root@server, funciona, sincroniza tudo como eu quero, é perfeito, mas eu meu receio é deixar a conexão ssh liberada para o root, mesmo que seja por chaves.

Estava querendo uma outra alternativa.

Porque você não deixa os arquivos indo para uma pasta temporaria e depois coloca um script do crontab para mover os arquivos para o diretório correto?

1 curtida

assim, eu falo isso mas o que eu faria é alterar a porta padrão do ssh, e transfiro com o usuario root mesmo (obviamente com uma senha dificil)

1 curtida

Atualmente esta desta forma, porem em alguns clientes acaba duplicando o espaço em disco e por alguns estarem em nuvem isso gera um custo a mais, pois um dos arquivos que são movidos são arquivos de BD com Postgre e MySql.

Porem essa sugestão funciona bem, esta rodando assim, tem um cron que envia para um servidor em um determinado horário neste pasta tempo e depois neste server outro cron que executa alguns minutos depois destinando a pasta correta.

Eu pensei que senão encontrar alternativa, uma seria esta, mudar a porta default do SSH, criar um usuário com outro nome e atribuir root a ele 0:0 e por fim a conexão SSH via chave.

Vou falar com a experiencia que tenho aqui na empresa. Nada é 100% seguro na internet, mas só de alterar a porta padrão do ssh e liberar acesso somente por chave já é quase que 99% seguro. Todos os servidores aqui na empresa estão nesse padrão e nunca tivemos problema.

Sobre o que você falou de criar um usuario novo não achei que tem muito sentido, se alguém conseguir acesso a esse usuario ou o root não terá diferença eu acho, ou entendi errado?

1 curtida

Acho que a lógica seja a mesma de alterar a porta SSH, evitar padrões para acesso como usuário root para dificultar alguém mal intencionado que tente root@servidor na porta 22.

1 curtida

ah sim, nesse caso tem sentido mesmo.

1 curtida

A ideia de ter outro usuário sendo o root seria justamente para evitar isso que o Ian comentou mesmo, caso alguém fique tentando com root@server em algumas portas ainda assim não vai. Pois eu teria um outro usuário, um admin por exemplo com permissão sudo para administração.

1 curtida

Não querendo ser bisbilhoteiro, mas ai na sua empresa estão trabalhando com distro em servidores?

Varia muito, depende do uso para o servidor, mas a maioria estamos usando oracle linux 7 ou 8. Também tem bastante cent os 7, porém sempre que possível estamos migrando eles para o Oracle Linux.

1 curtida

Vlw, é que aqui é um sistema novo que vai usar Linux como servidor default os legados ainda estao no Windows Server, mas estavamos em duvida entre Ubuntu Server e Fedora, entao em um cliente com Fedora em testes e estamos testando outro com Ubuntu Server (minha preferencia).

É bom não usar um nome previsível como admin ou $nome_da_distribuição. Não tenho a fonte aqui no ponto, mas já li que ataques de força bruta contra SSH geralmente tentar “driblar” o “sem root mas usuário com acesso ao sudo” justamente testando nomes de usuário previsíveis.

Geralmente pastas sob o /etc são 755 (o grupo só pode ler e listar os conteúdos, assim como os demais usuários).


Sugiro dar uma olhada na funcionalidade de daemon do rsync. Ela é feita justamente para esses cenários que você precisa garantir que a transferência será feita sob um usuário específico.

Porém, nesse cenário, necessariamente o rsync vai rodar como root, o que traz os seus próprios problemas (você tem que ficar super atento em CVEs do rsync, por exemplo).

O ideal é procurar uma solução que não vai exigir root no longo prazo.

2 curtidas

Vlw, eu vou dar uma pesquisa neste ponto citado por você " daemon do rsync", e ver como se comporta.

Estou marcando este post, pois definimos aqui como seguiremos e utilizei as dicas deste post de alterar a porta default do SSH e junto a isso alguns demais ajustes para garantir a segurança, como uso de chaves no SSH por exemplo.

Agradeço a todos que deram suas dicas, com certeza ajudou bastante na solução aqui.

1 curtida

Este tópico foi fechado automaticamente 3 dias depois da última resposta. Novas respostas não são mais permitidas.