Qual é a diferença entre o login como usuário e a alteração de usuários usando su através da raiz?

Quando você tem um servidor de algum tipo, pode acessá-lo através, por exemplo, ssh user1@ipe você também pode fazer isso ssh root@ippara acessar seu usuário root com privilégios su e depois acessar su user1. Na minha opinião, ambas as formas devem me levar ao mesmo ambiente de usuário (neste caso, "usuário1"), mas, na minha experiência real, não existe, porque ssh user1@iphá coisas instaladas que su user1não existem.

Por que é que?

O SSH inicia um shell de logon. su, por padrão, não.

Em particular, isso significa que o ~/.profile(ou arquivo semelhante) para esse usuário não é originado. Portanto, as alterações feitas ~/.profilenão terão efeito. Também pode ser que:

• mesmo se você iniciar um shell de logon, diferentes alterações foram feitas no root ~/.profile, o que pode poluir o ambiente do usuário.
  • /etc/profilee /etc/profile.d/*pode aplicar configurações de maneira diferente para usuários diferentes (embora não por padrão)
• pode haver configurações diferentes para usuários diferentes na configuração do SSH.

• A configuração do PAM é diferente. Por exemplo, /etc/pam.d/sshpossui:

  session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale
  

  considerando /etc/pam.d/suque:

  session       required   pam_env.so readenv=1 envfile=/etc/default/locale
  

  Isso significa que o SSH carrega ~/.pam_environment, mas sunão. Esse é um grande exemplo, pois ~/.pam_environmenté o local independente do shell para variáveis ​​de ambiente e será aplicado se você efetuar login na GUI, no TTY ou no SSH.

Para iniciar um shell de logon, execute um dos seguintes:

su - <username>
sudo -iu <username>

Exemplo:

# su muru -c 'sh -c "echo $HOME $PATH"'
/home/muru /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
# su - muru -c 'sh -c "echo $HOME $PATH"'
/home/muru /home/muru/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
# sudo -iu muru sh -c 'echo $HOME $PATH'
/home/muru /home/muru/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# sudo -u muru sh -c 'echo $HOME $PATH'
/root /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# ssh muru@localhost 'echo $HOME $PATH'
/home/muru /home/muru/devel/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Mesmo com o SSH, se você executar um comando em vez de iniciar um shell, um shell de login não será executado (observe a ausência de ~/binno teste SSH, que está presente em su -e sudo -i). Para obter o verdadeiro resultado, executarei meu shell como um shell de login:

# ssh muru@localhost '$SHELL -ilc "echo \$HOME \$PATH"'
/home/muru /home/muru/bin:/home/muru/devel/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

É também por isso sudo sue sudo -ssão maneiras ruins de obter um shell raiz. Ambas as formas são poluídas pelo meio ambiente.

Relacionado:

• Unix e Linux: su vs sudo -s vs sudo -i vs sudo bash

Em geral, é principalmente uma diferença estratégica.

Se você estiver logado como superusuário, poderá alterar qualquer coisa o tempo todo ... ou seja, não há proteção contra erros catastróficos, você precisará mudar temporariamente para outro usuário por segurança.

Visto que: se você está conectado com privilégios limitados, evita algum risco de erros catastróficos, porque precisa intencionalmente mudar para su root para obter acesso temporário a esse poder, mas agora tem a posição de retorno padrão para um usuário seguro .

A diferença é, portanto, realmente estratégica, não técnica.