Cuando tiene un servidor de algún tipo, puede acceder a él, por ejemplo, ssh user1@ipy también puede hacerlo ssh root@ippara ir a su usuario raíz con privilegios superiores y luego ir a su user1. En mi opinión, ambas formas deberían llevarme al mismo entorno de usuario (en este caso, "usuario1"), pero en mi experiencia real no lo hace, porque ssh user1@iphay cosas instaladas que su user1no hay.
¿Porqué es eso?
SSH inicia un shell de inicio de sesión. su, por defecto no lo hace.
En particular, esto significa que el ~/.profile(o archivo similar) para ese usuario no se obtiene. Por lo tanto, los cambios realizados ~/.profileno tendrán efecto. También podría ser el caso de que:
~/.profile, lo que podría contaminar el entorno del usuario.
/etc/profiley /etc/profile.d/*puede aplicar configuraciones de manera diferente para diferentes usuarios (aunque no de forma predeterminada)La configuración de PAM es diferente. Por ejemplo, /etc/pam.d/sshtiene:
session required pam_env.so user_readenv=1 envfile=/etc/default/locale
mientras que /etc/pam.d/sutiene:
session required pam_env.so readenv=1 envfile=/etc/default/locale
Esto significa que SSH se carga ~/.pam_environment, pero suno lo hace. Este es uno grande, ya que ~/.pam_environmentes el lugar independiente de la shell para las variables de entorno, y se aplica si inicia sesión desde la GUI, TTY o SSH.
Para iniciar un shell de inicio de sesión, ejecute cualquiera de:
su - <username>
sudo -iu <username>
Ejemplo:
# 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
Incluso con SSH, si ejecuta un comando en lugar de iniciar un shell, no se ejecutará un shell de inicio de sesión (tenga en cuenta la ausencia de ~/binen la prueba SSH, que está presente en su -y sudo -i). Para obtener el verdadero resultado, ejecutaré mi shell como un shell de inicio de sesión:
# 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
Esta es también la razón sudo suy sudo -sson formas desagradables de obtener un shell raíz. Ambas formas están contaminadas por el medio ambiente.
Relacionado:
En general, es principalmente una diferencia estratégica.
Si ha iniciado sesión como un superusuario, puede cambiar cualquier cosa todo el tiempo ... es decir, no hay protección contra errores catastróficos, tendría que cambiar temporalmente a otro usuario por seguridad.
Mientras que: si ha iniciado sesión con privilegios limitados, evita el riesgo de errores catastróficos, porque tiene que cambiar intencionalmente a su raíz para tener acceso temporal a ese poder, pero ahora tiene la posición de reserva predeterminada para un usuario seguro .
Por lo tanto, la diferencia es realmente estratégica, no técnica.
fuente