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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
