서버에서 특정 사용자가 갑자기 로그인이 안 된다는 제보가 들어왔을 때, 또는 새로 만든 계정이 docker 명령을 못 쓴다고 할 때 — 첫 번째로 확인해야 할 것이 이 세 파일입니다. Linux는 사용자 정보를 데이터베이스가 아닌 텍스트 파일로 관리하고, 각 파일이 다른 역할을 담당합니다. 이 파일들을 직접 읽을 줄 알면, id 명령 출력이 왜 그렇게 나오는지, 그룹 추가가 왜 바로 반영되지 않는지, 패스워드가 어디에 어떤 형태로 저장되는지를 모두 직접 확인할 수 있습니다.

확대

Linux의 사용자 정보는 세 개의 텍스트 파일에 나뉘어 저장됩니다.

/etc/passwd — 사용자 계정 데이터베이스

모든 사용자(사람 + 시스템 계정)가 한 줄씩 기록됩니다.

username:x:UID:GID:comment:home_dir:shell

실제 예시를 보면 다음과 같습니다.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
deploy:x:1001:1001:서비스 배포 계정:/home/deploy:/bin/bash

UID 범위별 역할

UID 숫자 범위에 따라 계정의 유형이 구분됩니다. 이 범위를 알면 낯선 시스템에서 /etc/passwd를 봤을 때 어떤 계정이 사람용이고 어떤 게 데몬용인지 바로 판별할 수 있습니다.

조합 해석 — 이 두 가지가 동시에 보이면:

• 시스템 계정(UID 1~999)인데 shell이 /bin/bash + 최근 로그인 기록 있음 → 계정 탈취 또는 설정 오류 의심, last <계정명>으로 로그인 이력 즉시 확인
• 일반 계정인데 sudo 그룹 + 퇴사 3개월 경과 → 접근 통제 누락, usermod -L <계정명>으로 잠금

두 번째 필드가 x인 것에 주목하세요. 실제 패스워드 해시는 여기에 없습니다.

/etc/shadow — 패스워드 해시 분리 저장

과거에는 패스워드 해시가 /etc/passwd에 직접 들어 있었습니다. 이 파일은 누구나 읽을 수 있기 때문에 오프라인 크래킹 공격에 노출됐습니다. 현대 Linux는 해시를 /etc/shadow로 분리하고, root만 읽을 수 있도록 권한을 640 또는 000으로 제한합니다.

username:$hash:last_change:min:max:warn:inactive:expire:reserved

deploy:$6$rounds=656000$salt$longhashstring...:19800:0:99999:7:::

각 필드의 의미입니다.

• $6$... — SHA-512 해시 (알고리즘 번호 6)
• 19800 — 마지막 패스워드 변경일 (1970-01-01 기준 일수)
• 99999 — 패스워드 최대 유효 기간 (일)
• 7 — 만료 7일 전부터 경고

보안 원칙: /etc/shadow는 절대 직접 편집하지 마세요. passwd, chage, usermod 명령을 사용하면 형식 오류 없이 안전하게 수정할 수 있습니다.

/etc/group — 그룹 멤버십

그룹 정보는 /etc/group 파일에 저장됩니다. 각 줄이 하나의 그룹이며, 쉼표로 구분된 사용자 목록이 마지막 필드에 옵니다.

groupname:x:GID:member1,member2,...

docker:x:998:alice,deploy
sudo:x:27:alice

사용자는 하나의 **주 그룹(primary group)**과 여러 개의 **보조 그룹(supplementary group)**에 속할 수 있습니다. 파일에 접근할 때 커널은 이 목록 전체를 확인합니다.

확대

새 계정을 만들었는데 SSH 로그인이 "안 되고", 비번은 맞는데 계정이 잠겼다 하고, 서비스 계정은 인증이 되는데도 접속하자마자 끊깁니다. 이 증상들은 전부 로그인 한 번에 순서대로 일어나는 조회 → 인증 → 자격증명 부여 → 셸 실행의 어느 한 단계가 막힌 것입니다. 로그인은 "비번이 맞나"만 보는 게 아니라, 앞서 본 /etc/passwd·/etc/shadow·/etc/group 세 파일을 차례로 거쳐 UID/GID라는 정체를 세션에 새기는 과정입니다. 이 흐름을 알면 "로그인이 안 된다"를 단계로 좁혀 진단할 수 있습니다.

[입력]  로그인: 사용자명 + 비밀번호   (login / sshd / su / sudo)
   │
   ① 조회: 사용자명으로 /etc/passwd 검색 → UID·주 GID·홈·셸 확인
   │
   ② 인증: 입력 비번을 해싱해 /etc/shadow 의 저장 해시와 대조 (PAM)
   │        └─ 동시에 faillock(실패 누적 잠금)·pwquality·계정 만료도 검사
   │
   ③ 자격증명: 인증 성공 → 세션 프로세스에 신원 부여
   │        UID · 주 GID(/etc/passwd) + 보조 그룹 목록(/etc/group)
   │
   ④ 환경: HOME=/home/<사용자> 로 이동, 로그인 셸(/etc/passwd 7번째 필드) 실행
   │
   ⑤ 초기화: 셸이 /etc/profile·~/.bash_profile 읽고 프롬프트 표시
   ▼
[세션]  이후 이 세션의 모든 프로세스가 ③의 UID/GID로 파일 접근·권한을 판정

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 "로그인이 안 된다"는 이 다섯 관문 중 하나가 막힌 것입니다. 비번 오류는 ②, 계정 잠금은 ②의 faillock, nologin 즉시 끊김은 ④, 그룹 변경이 반영 안 되는 것은 ③(재로그인 필요), 홈이 없어 생기는 문제는 ⑤입니다. 그래서 id <사용자>로 ③의 결과(UID·그룹)를, getent passwd <사용자>로 ①·④의 값(홈·셸)을 확인하면 어느 관문에서 막혔는지 바로 좁혀집니다.

파일을 직접 편집하는 대신, 다중 사용자 환경을 구축하고 권한을 분리할 때 쓰는 표준 명령이 있습니다. 이 명령들이 결국 위의 세 파일을 안전하게 갱신합니다 — 손으로 /etc/passwd를 고치다 한 글자 틀리면 로그인이 막히지만, 명령은 일관성을 보장합니다.

• useradd --create-home (또는 -m): 사용자를 새로 생성할 때 홈 디렉토리를 함께 자동 생성합니다. 이 옵션이 없으면 사용자는 로그인 시 홈 디렉토리가 없어 루트 디렉토리 /나 갈 곳 없는 환경에 놓입니다.
  로컬 터미널

  $ sudo useradd --create-home alice
  

  복사

  명령만 복사확대 보기
• usermod -aG: 기본 그룹을 유지하면서 보조 그룹(예: sudo, developers)에 추가합니다. -a(append)가 누락되면 기존 보조 그룹 정보가 전부 덮어써지는 사고가 납니다 — 반드시 -aG로 씁니다.
  로컬 터미널

  $ sudo usermod -aG sudo alice
  

  복사

  명령만 복사확대 보기
• id: 사용자의 현재 보안 식별자(uid, gid, 소속 groups)를 출력하는 검증 도구입니다. 변경 후 반영 여부를 확인할 때 씁니다.
  로컬 터미널

  $ id alice
  uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo)
  

  복사

  명령만 복사확대 보기

확대

배포 서버에 접속해서 Nginx를 재시작해야 하는데, 현재 계정으로는 권한이 없습니다. 이 상황에서 두 가지 선택지가 있습니다. root로 완전히 전환하거나, 이 명령 하나만 권한 상승해서 실행하거나. 전자가 su, 후자가 sudo입니다. 실무에서는 대부분 sudo가 더 안전한 선택입니다. 실행 내역이 로그에 남고, 권한 범위를 명령 단위로 제한할 수 있기 때문입니다. su는 여러 명령을 연속으로 실행해야 할 때나 root 환경이 필요한 경우에 씁니다.

su — 사용자 전환 (Switch User)

su는 다른 사용자로 완전히 전환합니다. 대상 계정의 패스워드가 필요합니다.

# root로 전환 (root 패스워드 필요)
su -

# 특정 사용자로 전환 (해당 사용자 패스워드 필요)
su - deploy

# 전환 없이 단일 명령만 실행
su - deploy -c "systemctl status myapp"

- (하이픈)는 중요합니다. 이것이 있으면 대상 사용자의 환경변수(PATH, HOME 등)까지 완전히 불러옵니다. 없으면 현재 환경을 유지한 채 사용자만 바뀌어 예상치 못한 동작이 생길 수 있습니다.

sudo — 특정 명령에 권한 위임 (Superuser Do)

sudo는 현재 사용자가 자신의 패스워드로 인증한 뒤 지정된 명령을 다른 사용자(보통 root) 권한으로 실행합니다. 모든 실행 내역이 /var/log/auth.log 또는 /var/log/secure에 기록됩니다.

# root 권한으로 단일 명령 실행
sudo apt update

# root 쉘로 진입
sudo -s

# 다른 사용자 권한으로 실행
sudo -u deploy ls /home/deploy

# 현재 계정에 부여된 sudo 권한 확인
sudo -l

/etc/sudoers 구조

visudo 명령으로만 편집하세요. 문법 검사를 자동으로 수행해 파일이 망가지는 것을 막아줍니다.

# 기본 문법
WHO WHERE=(AS_WHOM) WHAT

# alice는 어디서든 root로 모든 명령 실행 가능
alice ALL=(ALL) ALL

# deploy는 패스워드 없이 systemctl restart myapp만 실행 가능
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp

두 방법의 차이를 한 표로 정리하면 어떤 상황에서 무엇을 써야 할지 명확해집니다.

확대

비밀번호가 1234인 계정이 프로덕션 서버에 있다면, 브루트포스 공격에 몇 초도 안 걸립니다. 반대로 로그인 실패가 일정 횟수를 넘으면 자동으로 잠기는 정책이 있다면 공격 가능성이 크게 줄어듭니다. PAM은 이런 보안 정책을 시스템 전반에 일관되게 적용하는 Linux의 인증 프레임워크입니다. 패스워드 복잡도 요구사항, 로그인 실패 시 계정 잠금 — 이 두 가지가 기본 방어선이고, 여기서 다루는 설정이 그 구현입니다.

패스워드 관련 보안 정책은 PAM(Pluggable Authentication Modules)을 통해 시스템 전반에 일관되게 적용합니다. 설정 파일 위치는 배포판마다 다릅니다.

패스워드 품질 정책 (pwquality):

pwquality는 패스워드를 설정할 때 길이, 대소문자, 숫자, 특수문자 조건을 강제합니다. /etc/security/pwquality.conf에 정책을 정의하면 passwd 명령 실행 시 자동으로 적용됩니다.

# /etc/security/pwquality.conf 설정 예
sudo tee /etc/security/pwquality.conf << 'EOF'
minlen = 12          # 최소 12자
dcredit = -1         # 숫자 최소 1개 이상
ucredit = -1         # 대문자 최소 1개 이상
lcredit = -1         # 소문자 최소 1개 이상
ocredit = -1         # 특수문자 최소 1개 이상
maxrepeat = 3        # 같은 문자 3번 연속 금지
usercheck = 1        # 사용자명 포함 금지
EOF

# 설정 테스트 (패스워드 품질 점수 확인)
pwscore
# 입력: 12345        → 점수: 0 (너무 약함)
# 입력: P@ssw0rd123! → 점수: 100 (강함)

로그인 실패 잠금 정책 (pam_faillock):

pam_faillock은 지정한 횟수 이상 로그인에 실패하면 계정을 일시 잠금합니다. 브루트포스 공격의 기본 방어선입니다.

# RHEL 8+ / Rocky / AlmaLinux — /etc/security/faillock.conf
sudo tee /etc/security/faillock.conf << 'EOF'
deny = 5            # 5회 실패 시 잠금
fail_interval = 120 # 2분 안에 실패 횟수 집계
unlock_time = 300   # 5분 후 자동 잠금 해제 (0이면 영구 잠금)
silent              # 잠금 여부 숨기기 (보안 강화)
audit               # 잠금 이벤트를 audit 로그에 기록
EOF

# Ubuntu 22.04+ — /etc/pam.d/common-auth 확인
grep pam_faillock /etc/pam.d/common-auth

# 현재 잠긴 계정 확인
sudo faillock --user alice

# 계정 수동 잠금 해제 (관리자)
sudo faillock --user alice --reset

배포판별 PAM 설정 파일 위치:

Ubuntu와 RHEL 계열은 설정 파일 경로가 달라 혼동하기 쉽습니다. 서버 배포판을 확인한 뒤 해당 경로를 수정하세요.

운영 주의: PAM 설정을 잘못 적용하면 모든 사용자가 로그인 불가 상태가 됩니다. 변경 전 반드시 root 세션을 별도 유지하고, pam_config --service=sshd --query 또는 pamtester sshd <user> authenticate로 검증하세요.

지금까지 alice, deploy처럼 이름으로 계정을 다뤘습니다. 하지만 커널과 파일시스템은 그 이름을 전혀 모릅니다. 내부에서는 오직 숫자(UID/GID)만 저장하고 비교합니다. 이 사실을 알면 '이름은 다른데 권한이 새는' 당혹스러운 사고들의 정체가 보입니다.

• 이름은 라벨, 숫자가 정체: 파일 소유권은 inode에 UID/GID 숫자로 박히고, 커널의 권한 검사도 이 숫자만 봅니다. ls -l이 사용자 이름을 보여 주는 건 UID를 /etc/passwd에서 되짚어 표시하는 편의일 뿐입니다.
• 이름을 바꿔도 권한은 그대로: usermod -l로 이름만 바꿔도 UID가 같으면 그 계정이 소유하던 파일·권한은 하나도 바뀌지 않습니다. 반대로 이름이 같아도 UID가 다르면 완전히 다른 주체입니다.
• UID 재사용의 함정: userdel은 /etc/passwd에서 이름 항목만 지웁니다. 그 사용자가 남긴 파일은 여전히 옛 UID 소유로 디스크에 남고(고아 UID), 나중에 만든 새 계정이 같은 UID를 재할당받으면 그 옛 파일들을 소급 상속합니다 — 이름은 다른데 커널 눈엔 같은 사람.
• 컨테이너·NFS로 넘어가면 더 선명: 컨테이너 안 UID나 다른 호스트의 UID가 볼륨/NFS를 통해 같은 숫자면 같은 권한으로 취급됩니다. 컨테이너 안 root(UID 0)가 마운트한 호스트 파일을 root로 만지는 이유가 이것입니다.

정리하면 계정을 '이름'으로만 생각하면 반은 놓칩니다. 안전한 계정 회수란 이름을 지우는 것이 아니라, 그 UID가 남긴 흔적까지 정리하는 것입니다.

확대

CI/CD 파이프라인에서 배포 스크립트가 sudo systemctl restart myapp을 실행해야 한다면, 해당 계정에 sudo 전체 권한을 주는 건 과합니다. root 권한으로 모든 명령을 실행할 수 있게 되기 때문입니다. sudoers의 Cmnd_Alias를 쓰면 "이 계정은 이 명령만, 패스워드 없이"를 정밀하게 설정할 수 있습니다. 실무에서 서비스 계정의 sudo 권한을 설계할 때 가장 많이 쓰는 패턴입니다.

sudoers 파일은 최소 권한 원칙(Least Privilege)을 적용해 꼭 필요한 명령만 허용해야 합니다.

Cmnd_Alias로 명령 그룹화:

Cmnd_Alias는 관련 명령을 하나의 이름으로 묶어 sudoers 파일을 읽기 쉽게 유지하고, 추후 명령 추가·제거를 한 곳에서 관리할 수 있게 합니다.

# /etc/sudoers.d/deploy (visudo -f /etc/sudoers.d/deploy로 편집)

# 명령 그룹 정의
Cmnd_Alias DEPLOY_CMDS = /bin/systemctl restart myapp, \
                          /bin/systemctl start myapp, \
                          /bin/systemctl stop myapp, \
                          /usr/local/sbin/deploy-sync

Cmnd_Alias LOG_CMDS = /usr/bin/journalctl, \
                      /bin/tail

# 배포 계정에 명령 그룹 허용 (패스워드 없이)
deploy ALL=(root) NOPASSWD: DEPLOY_CMDS

# deploy-sync는 root:root 소유·쓰기 불가(0755)로 두고
# 소스·대상·옵션을 코드에 고정합니다. /usr/bin/rsync를 직접 허용하면
# --rsync-path 등 옵션으로 임의의 root 명령 실행이 가능해집니다.

# 개발자는 로그만 볼 수 있음
%developers ALL=(root) NOPASSWD: LOG_CMDS

# 특정 IP에서만 NOPASSWD 허용 (내부 CI/CD 서버 IP)
cicd 10.0.1.0/24=(root) NOPASSWD: DEPLOY_CMDS

NOPASSWD 사용 시 감사 보강:

NOPASSWD를 허용하면 패스워드 확인이 없어 편리하지만 그만큼 감사 로그가 중요해집니다. auditd를 함께 구성하면 sudoers 파일 자체의 변경 이력도 추적할 수 있습니다.

# sudo 실행 내역은 /var/log/auth.log 또는 /var/log/secure에 자동 기록
grep "sudo" /var/log/auth.log | grep "COMMAND"
# sudo: deploy : ... COMMAND=/bin/systemctl restart myapp

# auditd로 더 세밀한 감사 (설치 필요)
sudo apt install auditd
# /etc/audit/rules.d/sudo.rules
# -w /etc/sudoers -p wa -k sudoers_change
# -w /etc/sudoers.d/ -p wa -k sudoers_change
sudo augenrules --load

# sudo 실행 내역 감사 로그 확인
sudo ausearch -k sudoers_change

sudoers 파일 안전 편집 규칙:

/etc/sudoers를 직접 편집하다가 문법 오류가 생기면 sudo 자체가 잠겨 root 접근이 불가능해질 수 있습니다. visudo는 저장 전에 문법을 검사해 이를 방지합니다.

# 반드시 visudo 사용 (문법 검증 포함)
sudo visudo

# 특정 파일 편집
sudo visudo -f /etc/sudoers.d/deploy

# 문법 오류 있으면 저장 거부 → 파일 손상 방지
# 절대 직접 편집하지 말 것: sudo vi /etc/sudoers  ← 위험!

# 현재 자신의 sudo 권한 확인
sudo -l