Existe uma maneira confiável de fazer várias contas de usuários se comportarem como root, exceto sudo?

Question

Eu e um amigo estamos administrando um número razoável de máquinas virtuais, cada uma dedicada a alguma tarefa no sistema geral. Quando precisamos administrá-los, normalmente logamos como root, já que a única vez que fazemos login nas máquinas é quando precisamos executar tarefas administrativas nelas. Nós não usamos sudo, já que todo comando que fazemos normalmente é um comando sudo.

Preferiríamos manter nossas contas separadas nessas máquinas, para nos separar .bash_history, ver quando o outro estava conectado pela última vez, etc. Para fazer isso, precisaremos de duas contas com permissões de root completas.

Um método é alterar nossas contas de usuário normais para ter UID = 0 GID = 0, ou seja, o mesmo que root, no entanto, fui dissuadido dessa solução nesta pergunta: Existe alguma armadilha na concessão de privilégios de usuário root, tornando-os UID = 0 GID = 0?

[Essa pergunta é a mesma, até aqui]

A resposta nessa questão foi usar o sudo, mas como mencionei, o sudo é muito inconveniente para nosso caso de uso. Quase todos os comandos feitos nessas VMs são sudo-comandos (e | sudo tee >\dev\null para cada redirecionamento de saída é entorpecente!), Então o sudo provavelmente é mais inconveniente do que ter históricos separados e outro registro de contas é uma vantagem.

Minha pergunta de acompanhamento torna-se: Existe uma maneira confiável de fazer várias contas de usuários se comportarem como root, além do sudo? Ou existe uma maneira de tornar o sudo mais conveniente (além do sudo -i que derrota o propósito).

    

Answer 1

Se você usar sudo -s your $HOME não será atualizado, seu histórico de shell será mantido em sua própria conta.

(Lembre-se de que outros arquivos de configuração / histórico, como os criados por vim , também são criados como raiz. Isso significa que você pode acabar com arquivos de propriedade de root no diretório inicial. Isso pode criar " "situações interessantes quando você quiser modificá-las sem ser root, e ocasionalmente você precisará executar algo como chown -R myusername "$HOME" para consertá-lo.)

    

Answer 2

Veja como lidamos com isso em um trabalho anterior.

Primeiro, tivemos um host de bastião seguro que administra o login para todos os acessos raiz às máquinas de destino. Este host tinha uma conta especial keymaster configurada que possuía chaves privadas correspondentes à raiz nos hosts de destino. (Também tínhamos um sistema em que novos hosts se registravam automaticamente. Mas isso está fora do escopo aqui.)

Os administradores fazem login nesse host bastion com contas em nível de usuário e, em seguida, conectam-se aos sistemas de destino.

Exceto para poucos de nós com acesso ao root no próprio host do bastião, nenhum administrador pode acessar as chaves diretamente; em vez disso, eles usaram um comando connect executado sob sudo (como keymaster , não raiz) para se conectar. Esse comando connect configurou a variável de ambiente REMOTE_ADMIN para ser o nome do usuário de conexão e conectado como raiz ao sistema de destino.

Então , os sistemas remotos foram configurados para ter AcceptEnv=REMOTE_ADMIN em sshd_config e arquivos .bashrc para definir BASH_HISTORY para ~/.bash_history-$REMOTE_ADMIN .

Com essa configuração, os diferentes arquivos .bash_history não são registros seguros, mas são, pelo menos, distintos para fins de visualização não maliciosa do que aconteceu. O registro de segurança está no host bastião, mostrando quem se conectou quando. (Usamos 2FA para o comando sudo connect também.)

Além disso, além de subverter os hosts, não há necessidade de se preocupar com o acesso root fora do sistema designado (seja malicioso ou apenas por "conveniência"). E, embora as chaves possam ser removidas, não há necessidade de fazê-lo apenas porque o nível de acesso de alguém mudou.

Você pode usar toda ou parte dessa solução; simplesmente ter .bash_history-$SUDO_USER pode ser suficiente, dependendo do que você realmente está tentando realizar.