sudo / su / login shell - root 권한을 다루는 방법 (이론)

1. 개요 "금지된 명령입니다"

---

처음 고객사 서버에 접속했을 때의 일입니다. 환경변수 reload가 필요해서 습관적으로 su -를 입력했는데, 갑자기 세션이 끊기고, 접근제한 솔루션에서는 이런 문구가 떴습니다.

 

"금지 명령을 입력하여 계정이 잠겼습니다."

 

결국 단순히 설정 하나 바꾸려다 담당자에게 사과하며 계정 잠금을 해제해 달라고 요청해야 하는 민망한 상황이 벌어진 것이죠. 당시 제 생각은 단순했습니다. '이게 안 돼? 그럼 sudo -s를 해볼까? 아니면 sudo -i나 su - root는 되려나?' 하는 식으로, 그저 손에 익은 명령어들을 하나씩 대입해 보며 통과할 수 있는 '구멍'을 찾으려 했던 적도 있습니다.

 

실제로 어떤 서버에서는 su -는 막혀도 sudo -i로 넘어가면 해결되기도 합니다. 하지만 이런 대충 입력해서 대충 넘어가는 방식은 문제를 일으키기 딱 좋습니다. 현업의 운영 환경은 생각보다 훨씬 치밀해서 단순히 "운 좋게 맞는 명령어를 찾는 문제"가 아니기 때문입니다. 정책을 걸어놓은 이유가 분명 있을 것이기 때문이죠. 예를 들면 다음과 같은 이유들이 있을 수 있습니다.

• 엄격한 접근 제어: root 직접 로그인은 물론, 특정 우회 경로까지 실시간 감시 및 차단
• 제한된 명령어 세트: sudo 권한은 부여하지만, su - 처럼 아예 다른 사용자로 완전히 전환하는 행위는 정책적 금지
• 환경 변수의 늪: root 권한은 얻었으나, 이전 계정의 설정(PATH 등)이 그대로 남아 있어 실행 파일이 실행되지 않거나 설정이 꼬이는 현상

제가 무심코 입력한 su, su -, sudo -s, sudo -i는 단순한 타이핑 차이가 아닙니다. 이는 '로그인 셸(Login Shell)'의 작동 원리와 직결되며, 나아가 해당 서버가 채택한 '보안 정책과 책임 추적성'을 결정지을 수 있습니다.

도대체 어떤 명령어는 환경 변수를 그대로 계승하고, 어떤 명령어는 깨끗하게 비워진 새로운 환경을 만들어낼까요? 왜 어떤 곳에서는 sudo -s만 허용되는 걸까요? 

지금까지 적당하게 애매하게 넘어갔던 이런 이슈를 보안 아키텍처 관점에서 각 방식의 근본적인 차이를 다루고 이해해보고자 합니다.

 

 

2. 'sudo'와 'su' - root 권한을 다루는 두 가지 방식

---

리눅스에서 root 권한에 접근하는 방식은 크게 두 가지입니다. 바로 'sudo'와 'su'입니다.

하지만 이 두 방식의 차이는 단순히 명령어의 길이의 차이만 있는 것이 아닙니다. 서버를 어떻게 통제하고, 사고가 발생했을 때 어떻게 추적할 것인가에 대한 철학적 차이에 가깝습니다.

2.1 'su' — "root라는 계정이 된다"

먼저 'su' 에 대해 알아보겠습니다. su는 Switch User의 약자입니다. 말 그대로 사용자를 전환하는 명령어입니다.

su령을 치면, 현재 로그인한 계정을 로그아웃하지 않고 다른 사용자의 권한(일반적으로 root 관리자)으로 전환하여 쉘을 실행합니다.

su
su root

이 명령을 실행하면 현재 사용자는 root 계정으로 완전히 전환됩니다. 이후 실행하는 모든 명령은 root 권한으로 동작하게 됩니다.

여기서 가장 중요한 차이점: su는 root 계정의 비밀번호를 요구합니다.

[hun@server ~]$ su
Password: ← 여기서 입력하는 것은 root의 비밀번호

이 su를 실행하면, hun의 비밀번호가 아니라 root의 비밀번호를 입력해야 합니다. 즉, hun은 root 비밀번호를 알고 있어야만 su를 사용할 수 있습니다. 언뜻 보면 편리해 보이긴합니다. 한 번 전환하면 계속 root로 작업할 수 있으니까요. 하지만 실제 운영 환경에서는 심각한 문제들이 발생합니다.

 

1. 첫 번째 문제는 비밀번호 공유입니다. 여러 관리자가 su를 사용하려면 모두가 root 비밀번호를 알아야 합니다. 10명의 관리자가 있다면 10명 모두 같은 root 비밀번호를 공유하게 됩니다. 이 중 한 명이라도 퇴사하면 어떻게 될까요? 보안을 위해서는 비밀번호를 변경해야 하고, 다시 남은 9명 모두에게 새 비밀번호를 전달해야 합니다.

2. 두 번째 문제는 책임 추적의 어려움입니다. 어떤 관리자가 su로 root로 전환한 뒤 /etc/passwd 파일을 잘못 수정하여 시스템 장애가 발생했다고 가정해 보겠습니다. 로그를 확인해도 "root 계정이 실행했다"는 기록만 남을 뿐, 실제로 누가 그 작업을 했는지 알 수 없습니다. 10명의 관리자 중 누가 했는지 알아내려면 한명 한명 물어보는 방법밖에 없습니다.

3. 세 번째 문제는 권한의 지속성입니다. su로 root가 되면 명시적으로 exit하기 전까지 계속 root 상태입니다. 잠시 자리를 비운 사이 다른 사람이 터미널에 접근할 수도 있고, root 상태임을 인지하지 못한 채 위험한 명령을 입력할 수도 있습니다.

예를 들어 rm -rf * 를 잘못 입력했는데 그게 루트 디렉터리(/)였다면 시스템 전체가 복구 불가능한 아찔한 상황이 벌어질 수도 있습니다.

 

이러한 특성 때문에 su는 권한을 세밀하게 제한하는 것이 불가능하다는 구조적인 한계를 가지고 있습니다. 특정 명령어만 root 권한으로 실행하도록 제한할 수 없고, root의 모든 권한을 한 번에 넘겨주는 방식이기 때문입니다.

이런 이유들 때문에 su 또는 root 대상 su 자체를 막는 경우가 많습니다. 이것은 관리자를 불편하게 하려는 의도가 아니라, 시스템을 보호하고 사고 발생 시 원인을 추적하기 위한 필수적인 조치입니다.

root 비밀번호 노출을 최소화하고, 작업 이력을 명확히 남기며, 사고 발생 시 원인을 추적할 수 있도록 하기 위함이죠.

 

2.2 sudo — "root 권한을 잠깐 빌린다"

그럼 sudo는 su 와 어떤 차이가 있을까요? sudo는 su와는 동작 방식 자체가 다릅니다. 

google 검색 AI 개요

 

sudo는 일반 사용자가 관리자(root) 권한으로 명령을 일시적으로 실행할 수 있게 해주는 명령어입니다.

sudo 명령어

sudo 명령을 쳤을 때는 root 계정으로 전환하지 않습니다. 대신 특정 명령 하나만 root 권한으로 실행합니다. 명령이 끝나면 다시 일반 사용자로 돌아옵니다.

그리고 결정적인 차이로 sudo는 본인의 비밀번호를 요구합니다.

[hun@server ~]$ sudo systemctl restart nginx
[sudo] password for hun: ← 여기서 입력하는 것은 hun의 비밀번호

예를 들어 hun이 sudo를 실행하면, root의 비밀번호가 아니라 hun 계정의 비밀번호를 입력합니다. root 비밀번호를 전혀 몰라도 됩니다.

 

다시 정리해보면 'su'와 'sudo' 명령어가 요구하는 비밀번호는 아래와 같습니다.

su	root 계정의 비밀번호	root 비밀번호를 알아야 함
sudo	본인 계정의 비밀번호	자신의 비밀번호만 알면 됨

 

이 차이가 왜 중요할까요? 앞서 언급한 su 명령의 3가지 고질적인 문제점들이 sudo 체계에서는 어떻게 해결되는지 비교해 보면 명확해집니다.

 

1. 첫 번째, 비밀번호 공유의 문제점 -> sudo는 각자의 비밀번호를 사용한다.

sudo는 root 비밀번호가 아니라 본인의 비밀번호를 요구합니다. 10명의 관리자가 있어도 각자 자신의 계정으로 작업합니다. 누군가 퇴사하면 그 사람의 계정만 비활성화하면 됩니다.

su를 사용하려면

• hun이 root 비밀번호를 알아야 함
• mike도 root 비밀번호를 알아야 함
• sarah도 root 비밀번호를 알아야 함
• → 결과: 10명 모두 같은 root 비밀번호를 공유

반면 sudo를 사용하면

• hun은 hun의 비밀번호만 앎
• mike는 mike의 비밀번호만 앎
• sarah는 sarah의 비밀번호만 앎
• → 결과: 각자 자신의 비밀번호만 관리, root 비밀번호는 누구도 모름

현실적인 시나리오를 보았을 때, 회사에 관리자가 5명 있고, 모두 root 비밀번호를 공유하고 있다고 치겠습니다. 각 관리자들은 다음과 같은 방식으로 공유하고 있습니다.

관리자 A: root 비밀번호를 포스트잇에 적어 모니터에 붙임
관리자 B: root 비밀번호를 브라우저에 저장
관리자 C: root 비밀번호를 개인 노트북의 텍스트 파일에 저장
관리자 D: 퇴사 예정, 하지만 root 비밀번호는 여전히 알고 있음
관리자 E: 비밀번호를 잊어버려서 다른 사람에게 물어봄

이제 관리자 D가 퇴사합니다. 보안을 위해 root 비밀번호를 변경해야 합니다.

1. 새 root 비밀번호를 생성
2. 남은 4명 모두에게 전달 (메신저? 이메일? 전화?)
3. 4명이 각자 안전하지 않은 방법으로 또 저장
4. 누군가는 오래된 비밀번호로 계속 시도하다가 계정 잠김

하지만 sudo를 사용한다면

1. 관리자 D의 계정만 비활성화: usermod -L user_d
2. 끝

다른 관리자들은 아무 영향을 받지 않고, root 비밀번호는 애초에 공유되지 않았으므로 변경할 필요도 없습니다.

 

2. 두 번째, 책임 추적의 어려움 -> 모든 작업은 기록된다.

sudo는 기본적으로 /var/log/auth.log (또는 /var/log/secure)에 다음과 같은 정보를 남깁니다.

Feb 07 14:23:45 server01 sudo: username : TTY=pts/0 ; PWD=/home/username ; USER=root ; COMMAND=/bin/vim /etc/hosts

누가(username), 언제(14:23:45), 어디서(pts/0), 무엇을(vim /etc/hosts) 실행했는지 모두 기록됩니다. 문제가 발생하면 정확히 누구의 작업인지 알 수 있습니다.

 

3. 세 번째, 권한의 지속성 -> 최소 권한의 원칙을 구현한다.

sudo는 명령어를 실행하는 그 순간에만 root 권한을 부여하며, 명령 실행이 끝나면 권한은 즉시 회수됩니다.

또한, sudoers 설정을 통해 특정 사용자에게 특정 명령어만 허용할 수 있습니다. 예를 들어, 웹서버 관리자에게는 systemctl restart nginx만 허용하고, 파일 시스템 전체를 건드리는 권한은 주지 않을 수 있습니다.

 

 

3. login shell — su, su -, sudo의 본질적 차이

---

이제 제가 실제로 가장 큰 혼란을 겪었던 부분을 이야기해 보겠습니다. 분명 sudo -s를 통해 root 셸에 진입했는데, 어떤 명령어는 잘 실행되고 어떤 명령어는 "command not found"가 뜹니다.

 

프롬프트는 분명 #(root)인데 왜 이런 일이 벌어질까요? 문제는 "root가 되었느냐"가 아니라, "어떤 셸(Shell) 상태로 들어왔느냐"에 있습니다.

3.1 login shell이란 무엇이고, 왜 중요한가?

login shell은 말 그대로 "로그인할 때 실행되는 셸"입니다. 서버에 SSH로 접속하거나, 콘솔에서 로그인할 때 실행되는 첫 셸이 login shell입니다.

왜 이것이 중요할까요? login shell에서는 다음과 같은 초기화 파일들이 순서대로 실행되기 때문입니다.

1. /etc/profile - 시스템 전역 설정
2. ~/.bash_profile 또는 ~/.profile - 사용자별 설정
3. ~/.bashrc (일부 경우)

이 파일들에서 무엇을 설정할까요?

PATH 환경 변수: 명령어를 찾을 디렉토리 경로입니다. /usr/local/bin:/usr/bin:/bin과 같은 값이 여기서 설정됩니다. PATH가 없으면 ls, cat 같은 기본 명령어조차 전체 경로(/bin/ls)를 입력해야 합니다.

환경 변수: JAVA_HOME, ORACLE_HOME, LD_LIBRARY_PATH 등 애플리케이션이 동작하는 데 필요한 설정들입니다.

Alias와 함수: 자주 쓰는 명령어의 단축어나 커스텀 함수들입니다.

프롬프트 설정: PS1 변수로 터미널 프롬프트의 모양을 결정합니다.

만약 이런 초기화가 이루어지지 않으면 어떻게 될까요? root가 되더라도 제대로 된 작업 환경을 갖추지 못합니다. 이것이 바로 su와 su -의 차이를 만드는 핵심입니다.

3.2 su 와 su - 의 결정적 차이

su (login shell ❌)

su

이 명령은 root 계정으로 전환하지만 현재 환경을 그대로 유지합니다.

# 일반 사용자 hun으로 작업 중
[hun@server ~]$ echo $PATH
/home/hun/bin:/usr/local/bin:/usr/bin:/bin

[hun@server ~]$ echo $HOME
/home/hun

# su로 root가 됨
[hun@server ~]$ su
Password: 

# root가 되었지만 환경은 hun의 것
[root@server hun]# echo $PATH
/home/hun/bin:/usr/local/bin:/usr/bin:/bin  # hun의 PATH

[root@server hun]# echo $HOME
/home/hun  # hun의 홈 디렉토리

[root@server hun]# pwd
/home/hun  # 현재 디렉토리도 hun의 홈

겉보기엔 root지만 실제로는 hun의 환경에서 root 권한만 빌린 상태입니다. 이런 상황에서 무슨 문제가 생길까요?

 

문제 1: 명령어를 찾지 못합니다. root 전용 명령어들(ifconfig, fdisk 등)은 보통 /sbin 이나 /usr/sbin에 있습니다. 하지만 일반 사용자의 PATH에는 이런 경로가 없을 수 있습니다.

문제 2: 설정 파일을 잘못 읽습니다. 일부 프로그램은 $HOME을 기준으로 설정 파일을 찾습니다. root로 작업하는데 hun의 설정을 읽게 될 수 있습니다.

문제 3: 예상치 못한 동작이 발생합니다. hun의 .bashrc에 정의된 alias나 함수가 그대로 적용되어, root로 작업하는데 일반 사용자의 커스텀 설정이 개입합니다.

su - (login shell ⭕)

su -

이 명령은 완전히 다릅니다. root 계정으로 새로 로그인하는 것처럼 동작합니다.

# 일반 사용자 hun으로 작업 중
[hun@server ~]$ echo $PATH
/home/hun/bin:/usr/local/bin:/usr/bin:/bin

[hun@server ~]$ echo $HOME
/home/hun

# su -로 root 환경으로 완전 전환
[hun@server ~]$ su -
Password: 

# 완전히 root의 환경
[root@server ~]# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin  # root의 PATH

[root@server ~]# echo $HOME
/root  # root의 홈 디렉토리

[root@server ~]# pwd
/root  # root의 홈에서 시작

su - 는 다음과 같은 과정을 거칩니다.

1. root의 login shell을 시작합니다
2. /etc/profile을 읽습니다
3. /root/.bash_profile을 읽습니다
4. 현재 디렉토리를 /root로 변경합니다
5. 모든 환경 변수를 root 기준으로 재설정합니다

결과적으로 SSH로 root 계정에 직접 로그인한 것과 거의 동일한 환경을 얻게 됩니다.

3.3 그렇다면 언제 무엇을 써야 할까?

su를 쓸 때: 현재 디렉토리와 환경을 유지한 채 잠깐 root 권한이 필요할 때입니다. 하지만 실무에서는 거의 사용하지 않습니다. 예상치 못한 환경 문제가 발생할 수 있기 때문입니다.

su -를 쓸 때: 완전히 root로 작업해야 할 때입니다. 시스템 설정을 변경하거나, root 전용 명령어를 여러 개 실행해야 할 때 사용합니다. 하지만 보안 정책상 이것조차 막혀있는 경우가 많습니다.

실무에서는 대부분 sudo를 사용하게 됩니다. 물론 sudo에서도 비슷한 차이가 있습니다.

 

 

4. "sudo -s" 와 "sudo -i"

---

su와 su -의 차이를 이해했다면, sudo에서도 동일한 개념이 적용된다는 것을 예상할 수 있을 것입니다. sudo에서도 shell 관련 옵션이 있으며, 이를 이해하지 못하면 환경 문제가 계속 반복됩니다.

4.1 sudo -s — "환경은 그대로, 권한만 root"

sudo -s

이 명령은 다음과 같이 동작합니다.

• root shell을 실행합니다
• 현재 사용자의 환경을 유지합니다
• login shell이 아닙니다

즉, su와 유사한 동작입니다. 차이는 root 비밀번호가 아니라 본인 비밀번호를 사용한다는 점입니다.

# 일반 사용자 hun의 환경
[hun@server ~]$ echo $PATH
/home/hun/bin:/usr/local/bin:/usr/bin:/bin

[hun@server ~]$ echo $HOME
/home/hun

# sudo -s로 root shell 진입
[hun@server ~]$ sudo -s

# root이지만 hun의 환경
[root@server hun]# echo $PATH
/home/hun/bin:/usr/local/bin:/usr/bin:/bin  # hun의 PATH

[root@server hun]# echo $HOME
/home/hun  # hun의 홈

[root@server hun]# pwd
/home/hun  # 현재 디렉토리도 유지

언제 이것을 사용할까요? 현재 작업 중인 디렉토리에서 여러 root 명령을 연속으로 실행해야 할 때 유용합니다. 예를 들어, /var/www/html 디렉토리에서 파일 권한을 변경하고, 소유자를 바꾸고, 새 파일을 생성해야 한다면:

cd /var/www/html
sudo -s
# 이제 /var/www/html에서 계속 작업 가능
chown www-data:www-data index.html
chmod 644 index.html
touch new_page.html

4.2 "sudo -i" — "root로 로그인한 것처럼"

sudo -i

이 명령은 완전히 다릅니다.

• root login shell을 실행합니다
• /etc/profile, /root/.bash_profile 등을 로딩합니다
• su -와 가장 유사한 동작을 합니다

# 일반 사용자 hun의 환경
[hun@server ~]$ echo $PATH
/home/hun/bin:/usr/local/bin:/usr/bin:/bin

[hun@server ~]$ echo $HOME
/home/hun

# sudo -i로 root login shell 진입
[hun@server ~]$ sudo -i

# 완전히 root의 환경
[root@server ~]# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin  # root의 PATH

[root@server ~]# echo $HOME
/root  # root의 홈

[root@server ~]# pwd
/root  # root의 홈에서 시작

 

4.3 비교표

명령어	login	shell 환경 유지	필요한 비밀번호	작업 디렉토리
su	❌	기존 환경 유지	root 비밀번호	현재 디렉토리
su -	⭕	root 환경으로 초기화	root 비밀번호	/root
sudo -s	❌	기존 환경 유지	본인 비밀번호	현재 디렉토리
sudo -i	⭕	root 환경으로 초기화	본인 비밀번호	/root

 

# su 계열 - root 비밀번호 필요
[hun@server ~]$ su
Password: ← root의 비밀번호 입력
[root@server hun]# 

[hun@server ~]$ su -
Password: ← root의 비밀번호 입력
[root@server ~]# 

# sudo 계열 - 본인 비밀번호만 필요
[hun@server ~]$ sudo -s
[sudo] password for hun: ← hun의 비밀번호 입력
[root@server hun]# 

[hun@server ~]$ sudo -i
[sudo] password for hun: ← hun의 비밀번호 입력
[root@server ~]# 

 

4.4 실무에서의 선택 기준

단일 명령어만 실행: 그냥 sudo 명령어를 사용합니다.

sudo systemctl restart nginx

여러 명령어를 현재 디렉토리에서 실행: sudo -s를 사용합니다.

cd /var/log
sudo -s
# 로그 파일들을 연속으로 확인
tail -f messages
grep ERROR syslog

시스템 설정 변경 등 완전한 root 환경 필요: sudo -i를 사용합니다.

sudo -i
# root 환경에서 시스템 설정 작업
vi /etc/ssh/sshd_config
systemctl restart sshd

 

 

5. 마무리

---

sudo와 su가 이렇게까지 민감하게 다뤄지는 이유는 명확합니다. 이 영역에서 발생하는 취약점은 대부분 root 권한 탈취로 이어지고, 결과적으로 시스템 장악까지 일어날 수 있습니다. 보안 위협사례에 대해서 따로 다루지 않아 와닿지 않게 느껴질 수 있으나 이와 관련되어 아주 잘 정리되어 있는 글을 하단에 남기며, 마무리 하도록 하겠습니다.

다음 포스팅에서는 sudo 권한에 대한 이론을 바탕으로 실습을 진행해보겠습니다.

 

 

참고하면 좋은 글

https://www.igloo.co.kr/security-information/sudo-%EC%B7%A8%EC%95%BD%EC%A0%90-%EB%B6%84%EC%84%9D-%EB%B0%8F-%EB%8C%80%EC%9D%91%EB%B0%A9%EC%95%88-part-1/

Sudo 취약점 분석 및 대응방안 part.1