Kiedy masz jakiś serwer, możesz uzyskać do niego dostęp, np. ssh user1@ipI możesz także ssh root@ipprzejść do użytkownika root z uprawnieniami su, a następnie przejść do su user1. W moim przekonaniu oba te sposoby powinny doprowadzić mnie do tego samego środowiska użytkownika (w tym przypadku „użytkownika 1”), ale z mojego rzeczywistego doświadczenia tak nie jest, ponieważ ssh user1@ipsą zainstalowane rzeczy, których su user1nie ma.
Dlaczego?
SSH uruchamia powłokę logowania. su, domyślnie nie.
W szczególności oznacza to, że ~/.profile(lub podobny plik) dla tego użytkownika nie jest pozyskiwany. Wprowadzone zmiany ~/.profilenie będą obowiązywać. Może się również zdarzyć, że:
~/.profile, które mogą zanieczyścić środowisko użytkownika.
/etc/profilei /etc/profile.d/*może stosować ustawienia inaczej dla różnych użytkowników (jednak nie domyślnie)Konfiguracja PAM jest inna. Na przykład /etc/pam.d/sshma:
session required pam_env.so user_readenv=1 envfile=/etc/default/locale
mając na uwadze, /etc/pam.d/suże:
session required pam_env.so readenv=1 envfile=/etc/default/locale
Oznacza to, że SSH ładuje się ~/.pam_environment, ale sunie. To jest duże, ponieważ ~/.pam_environmentjest niezależnym od powłoki miejscem dla zmiennych środowiskowych i jest stosowane, jeśli logujesz się z GUI, TTY lub SSH.
Aby uruchomić powłokę logowania, uruchom jedną z:
su - <username>
sudo -iu <username>
Przykład:
# 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
Nawet w przypadku SSH, jeśli uruchomisz polecenie zamiast uruchamiania powłoki, powłoka logowania nie zostanie uruchomiona (zwróć uwagę na brak ~/bintestu SSH, który jest obecny w su -i sudo -i). Aby uzyskać prawdziwy wynik, uruchomię moją powłokę jako powłokę logowania:
# 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
Jest to również powód sudo sui sudo -ssą kiepskimi sposobami na uzyskanie powłoki roota. Oba te sposoby są zanieczyszczone przez środowisko.
Związane z:
Zasadniczo jest to głównie różnica strategiczna.
Jeśli jesteś zalogowany jako superużytkownik, możesz cały czas zmieniać wszystko ... tzn. - nie ma ochrony przed katastrofalnymi błędami, dla bezpieczeństwa musisz tymczasowo zmienić się na innego użytkownika.
Podczas gdy: jeśli jesteś zalogowany z ograniczonymi uprawnieniami, unikasz pewnego ryzyka katastrofalnych błędów, ponieważ musisz celowo przejść do rootowania, aby uzyskać tymczasowy dostęp do tej mocy, ale teraz masz domyślną pozycję awaryjną dla bezpiecznego użytkownika .
Różnica jest więc naprawdę strategiczna, a nie techniczna.
źródło