Recomendamos que você use apenas a conta raiz. Se você configurá-lo assim:
- Configure seu
sshd_configna máquina de destino paraPermitRootLogin without-password. - Use
ssh-keygenna máquina que puxa o backup para criar uma chave privada SSH (somente se você ainda não tiver uma chave SSH). Não defina uma frase secreta. Google um tutorial se você precisar de detalhes para isso, deve haver muito. - Anexe o conteúdo de
/root/.ssh/id_rsa.pubda máquina de backup ao/root/.ssh/authorized_keysde sua máquina de destino. - Agora, sua máquina de backup tem acesso raiz à sua máquina de destino, sem precisar usar a autenticação de senha.
a configuração resultante deve ser bastante segura.
sudo , especialmente combinado com NOPASSWD , conforme recomendado nos comentários, não tem benefícios de segurança apenas com o uso da conta raiz. Por exemplo, esta sugestão:
add the following to your
/etc/sudoersfile:rsyncuser ALL= NOPASSWD:/usr/bin/rsync
essencialmente concede rsyncuser de permissões de raiz. Você pergunta:
@MartinvonWittich Easy to gain a full root shell because
rsyncexecuted withsudo? Walk [m]e [through] that please.
Bem, simples. Com a configuração recomendada, rsyncuser agora pode executar rsync como root sem ter uma senha solicitada. rsync é uma ferramenta muito poderosa para manipular arquivos, então agora rsyncuser tem uma ferramenta muito poderosa para manipular arquivos com permissões de root. Encontrar uma maneira de explorar isso me levou apenas alguns minutos (testado no Ubuntu 13.04, requer dash , bash não funcionou):
martin@martin ~ % sudo rsync --perms --chmod u+s /bin/dash /bin/rootdash
martin@martin ~ % rootdash
# whoami
root
# touch /etc/evil
# tail -n1 /etc/shadow
dnsmasq:*:15942:0:99999:7:::
Como você pode ver, eu criei um shell de raiz; whoami identifica minha conta como root, posso criar arquivos em /etc e posso ler em /etc/shadow . Meu exploit era definir o bit setuid no dash binário; Isso faz com que o Linux sempre execute esse binário com as permissões do proprietário, neste caso, root.
Having a real root is not [recommended] for good reasons. – redanimalwar 15 hours ago
Não, trabalhar desajeitadamente em torno da conta raiz em situações em que é absolutamente apropriado usá-la não é por boas razões. Esta é apenas outra forma de programação de cultos de carga - você não entende realmente o conceito por trás do sudo vs root, você apenas cegamente aplique a crença "raiz é ruim, sudo é bom" porque você leu isso em algum lugar.
Por um lado, há situações em que sudo é definitivamente a ferramenta certa para o trabalho. Por exemplo, quando você está trabalhando interativamente em um desktop gráfico Linux, digamos que o Ubuntu, então usar sudo é bom nos raros casos em que às vezes você precisa de acesso root. O Ubuntu intencionalmente tem uma conta root desativada e obriga você a usar sudo por padrão para evitar que os usuários usem a conta root apenas para efetuar login. Quando o usuário apenas deseja usar, por exemplo, o navegador da Web, em seguida, fazer login como root seria uma coisa perigosa e, portanto, não ter uma conta root por padrão impede que pessoas estúpidas façam isso.
Por outro lado, há situações como a sua, em que um script automatizado requer permissões de root para algo, por exemplo, para fazer um backup. Agora, usar sudo para contornar a conta raiz não é apenas inútil, mas também perigoso: à primeira vista, rsyncuser parece uma conta comum sem privilégios. Mas como já expliquei, seria muito fácil para um invasor obter acesso root completo se ele já tivesse ganhado rsyncuser access. Então, basicamente, agora você tem uma conta root adicional que não se parece com uma conta root, o que não é uma coisa boa.