Rescue 모드에서 인증 장애 복구: /etc/shadow·unix_chkpwd·init 실행 실패 점검
권한/보안 점검 조치 이후 로그인 불가 또는 /sbin/init 실행 실패까지 번질 때, 단계별로 원인 분기와 복구를 진행합니다.
개요
사용자 인증 체계(PAM)는 /etc/shadow를 일반 사용자에게 직접 노출하지 않도록 설계되어 있고,
대신 인증 과정에서 필요한 접근을 unix_chkpwd 같은 헬퍼가 담당합니다.
여기서 권한(특히 SUID)이나 파일 접근이 끊기면 SSH, sudo, su가 연쇄로 실패해
“서버가 죽은 것처럼” 보일 수 있습니다.
SELinux 컨텍스트, 루트 마운트 상태, 파일시스템 손상(I/O error)까지 같이 엮여 “부팅 실패(/sbin/init)”로 번질 수 있습니다.
그래서 아래처럼 단계형 분기로 접근하는 게 가장 안전합니다.
환경
아래 환경을 가정합니다. (다르더라도 흐름은 동일합니다.)
- RHEL/Rocky/CentOS 계열 (systemd 기반)
- Rescue/Single user 모드로 진입 가능
- 보안 점검/하드닝 과정에서 SUID/권한 변경 이력 존재
- 일부 rescue 환경에서
dnf/yum/find/touch가 없을 수 있음
증상
sudo/su 실패
PAM 관련 서비스 기동 실패
Failed to execute /sbin/initFailed to execute fallback shellchroot 시
/bin/sh Input/output error
반면
/sbin/init 실패나 Input/output error가 있으면 권한 문제가 아니라
systemd/glibc 손상 또는 파일시스템/디스크 문제로 분기해야 합니다.
1차 점검
1) 최소 확인: shadow와 unix_chkpwd 기본값
정상 구성의 대표 조합은 다음입니다.
| 대상 | 권장 상태 | 의미 |
|---|---|---|
/etc/shadow |
0400 / 소유자 root:root |
shadow는 root만 읽을 수 있어야 함 |
unix_chkpwd |
4750 / 소유자 root:root |
SUID로 인증 과정에서 shadow 접근을 대행 |
2) 부팅 가능(로그인 가능)한 경우 즉시 확인
ls -l /etc/shadow
ls -l /sbin/unix_chkpwd 2>/dev/null
ls -l /usr/sbin/unix_chkpwd 2>/dev/null
3) Rescue에서 루트 파일시스템 RW + 바인드 마운트
mount -o remount,rw /sysroot
mount --bind /dev /sysroot/dev
mount --bind /proc /sysroot/proc
mount --bind /sys /sysroot/sys
mount --bind /run /sysroot/run
/bin/sh Input/output error)하면 권한 복구보다 먼저파일시스템 점검(xfs_repair/fsck)로 분기해야 합니다.
심화 분석
분기 A: 인증만 막힘(SSH/sudo/su 실패) — OS는 부팅됨
대부분 다음 케이스 중 하나입니다.
unix_chkpwd에서 SUID 제거됨 (4750 → 0750)/etc/shadow권한이 과도하게 잠김 (000등)- SELinux 컨텍스트 꼬임(라벨 손상)
분기 B: Failed to execute /sbin/init — init/systemd 경로 문제
이 메시지가 반복되면 인증 파일만 복구해도 해결되지 않습니다.
/sbin/init 링크/권한, /usr/lib/systemd/systemd 존재 여부,
그리고 SELinux 재라벨이 핵심입니다.
ls -l /sysroot/sbin/init
ls -l /sysroot/usr/lib/systemd/systemd
분기 C: Input/output error — 파일시스템/디스크 손상 의심
이 경우는 “권한 복구”가 아니라 “읽기 자체가 안 되는 상태”를 먼저 해결해야 합니다.
# 루트 디바이스/FS 타입 확인
lsblk -f
xfs_repair, ext 계열이면 fsck로 점검합니다.rescue 환경에 해당 명령이 없다면 설치 미디어(또는 더 기능이 많은 rescue 이미지)로 교체가 필요할 수 있습니다.
복구
1) 인증 복구(표준 권장)
가장 안전한 표준 복구입니다. (가능하면 이 조합으로 복귀)
chown root:root /sysroot/etc/shadow
chmod 400 /sysroot/etc/shadow
# unix_chkpwd 경로는 환경별로 다를 수 있어 2개 모두 시도
[ -e /sysroot/sbin/unix_chkpwd ] && chown root:root /sysroot/sbin/unix_chkpwd && chmod 4750 /sysroot/sbin/unix_chkpwd
[ -e /sysroot/usr/sbin/unix_chkpwd ] && chown root:root /sysroot/usr/sbin/unix_chkpwd && chmod 4750 /sysroot/usr/sbin/unix_chkpwd
2) init 실행 실패 복구(링크/권한 + SELinux 재라벨)
# /sbin/init이 systemd로 연결되는 구조를 강제로 정리
ln -sf /usr/lib/systemd/systemd /sysroot/sbin/init
chown root:root /sysroot/sbin/init
chmod 755 /sysroot/sbin/init
chown root:root /sysroot/usr/lib/systemd/systemd
chmod 755 /sysroot/usr/lib/systemd/systemd
SELinux를 쓰는 환경이면 재라벨 예약 파일을 생성합니다. touch가 없으면 echo로 대체합니다.
echo > /sysroot/.autorelabel
3) 재부팅
reboot
시간이 오래 걸려도 정상 동작일 수 있습니다.
4) 부팅 후 확인
ls -l /etc/shadow
ls -l /sbin/unix_chkpwd 2>/dev/null
ls -l /usr/sbin/unix_chkpwd 2>/dev/null
ls -l /sbin/init
ls -l /usr/lib/systemd/systemd
재발 방지
1) SUID/SGID 점검에서 “예외” 기준을 명확히
SUID/SGID 최소화는 원칙적으로 맞지만, unix_chkpwd처럼 인증 체계에 필수인 구성요소는 예외가 필요합니다.
운영 환경에서는 “제거”보다 “필수 파일 식별 + 무결성 확인 + 접근 통제”가 더 안전합니다.
2) 변경 전후 체크리스트
- 변경 전:
ls -l /etc/shadow,ls -l (unix_chkpwd 경로)기록 - 변경 후: SSH, sudo, su 최소 1회 동작 확인
- SELinux 사용 시: 컨텍스트 손상 가능성 고려(필요 시 재라벨 계획 포함)
3) Rescue 환경 준비
- 복구 매체는 “명령이 충분한” 이미지로 준비 (dnf/yum, xfs_repair/fsck 포함)
- ISO/IODD 사용 시: CD-ROM(iso9660) 모드 전환 방법 숙지
- 네트워크 복구 절차(인터페이스 up, DHCP, DNS) 문서화
/etc/shadow는 root만 읽도록 유지하고(보통 0400),unix_chkpwd는 인증 흐름을 위해 SUID(4750)가 필요한 경우가 많습니다.여기에
/sbin/init 실행 실패나 I/O error가 섞이면 권한 문제가 아니라
systemd/FS/SELinux까지 같이 복구해야 합니다.
'지식 공유 > Server' 카테고리의 다른 글
| 리눅스 커널 로그에서 SYN 반복 유입 확인과 대응 (0) | 2026.04.15 |
|---|---|
| 리눅스 SWAP 확인부터 스왑 메모리 증설 (0) | 2026.03.10 |
| Rocky8 취약점 패키지 조치 (1) | 2025.12.24 |
| 리눅스 Landlock 설정 - 샌드박스 (0) | 2025.12.04 |
| RAID 구성 종류와 방식 (1) | 2025.12.03 |
