Rescue 모드에서 인증 장애 복구: /etc/shadow·unix_chkpwd·init 실행 실패 점검

반응형
Rescue 모드에서 인증 장애 복구: /etc/shadow·unix_chkpwd·init 실행 실패 점검

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가 없을 수 있음

증상

인증 계열 증상 SSH 로그인 실패
sudo/su 실패
PAM 관련 서비스 기동 실패
부팅/시스템 계열 증상 Failed to execute /sbin/init
Failed to execute fallback shell
chroot 시 /bin/sh Input/output error
중요 인증만 깨진 상태라면 “OS는 살아있는데 접속이 막힌 상태”일 가능성이 큽니다.
반면 /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
chroot가 안 되면? chroot 자체가 실패(/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
참고 분기 FS가 XFS면 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
부팅 중 주의 SELinux relabel(재라벨) 메시지가 나오면 중간에 끄지 말고 끝까지 진행합니다.
시간이 오래 걸려도 정상 동작일 수 있습니다.

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까지 같이 복구해야 합니다.
반응형