root도 부팅도 막혔다 — GRUB 명령줄에서 서버를 되살리기

권한 복구를 하려다 부팅 문제를 만나다

보안 취약점 대응으로 RHEL 8 서버의 OpenSSL을 업그레이드한 직후 root 권한을 얻을 수 없게 됐다. 일반 계정으로는 로그인할 수 있었지만 권한을 높일 수 없어 변경 사항을 되돌리기도 어려웠다. 내가 맡은 일은 이 상태의 서버를 복구하는 것이었다.

라이브러리를 교체하면 이를 사용하는 프로그램에 호환성 문제가 생길 수 있다. 하지만 당시 실패한 인증 모듈이나 교체된 파일을 특정할 기록은 충분하지 않다. sudo, sshd, PAM 전체가 같은 이유로 망가졌다고 설명하기보다, 업그레이드 직후 권한 획득이 막혔다는 관찰에서 출발해야 한다.

복구용 환경으로 들어가 OpenSSL을 되돌리려 재부팅했다. 그런데 예상한 부팅 메뉴 대신 grub> 프롬프트가 나타났다. 권한 문제를 고치기 전에 운영체제를 수동으로 시작할 경로부터 찾아야 했다.

먼저 프롬프트를 구분한다

grub>는 GRUB 명령줄이며 grub rescue>와 같지 않다. 원문에서는 두 상태를 모두 rescue 셸이라고 불렀지만, rescue 모드에서는 보통 insmod, ls, set, unset처럼 사용할 수 있는 명령이 제한된다. 아래의 linux, initrd, boot 흐름을 rescue 프롬프트에 그대로 적용할 수 있다고 보면 안 된다. GNU GRUB 명령 안내

GNU GRUB 문서에 따르면 rescue 셸은 보통 normal 모듈을 불러오지 못했을 때 나타난다. 이 경우에는 모듈 위치를 가리키는 prefix와 장치, 파일시스템 접근부터 확인해야 한다. 이번 기록의 grub> 프롬프트만으로 grub.cfg가 손상됐거나 읽기에 실패했다고 확정할 수는 없다. GRUB rescue 진단

내가 수행한 복구는 GRUB 명령줄에서 부팅 파일을 찾아 커널을 올리는 방식이었다. 다음 도표는 그 작업 흐름을 보여준다. 화살표는 복구 단계의 순서이며, OpenSSL 변경이 GRUB 문제를 일으켰다는 인과를 나타내지는 않는다.

도표 크게 보기

부팅 파일을 찾아 수동으로 시작하기

먼저 ls로 GRUB가 인식한 디스크와 파티션을 확인했다. 이어 각 파티션의 파일 목록을 살펴 vmlinuz와 대응하는 initramfs를 찾았다. 당시 복구 기록을 바탕으로 정리한 명령은 다음과 같다. grub>는 프롬프트 표시이며 입력할 명령의 일부가 아니다.

grub> ls
grub> ls (hd0,gpt2)/
grub> set root=(hd0,gpt2)
grub> linux /vmlinuz-4.18.0-553.8.1.el8_10.x86_64 root=/dev/mapper/rootvg-root ro init=/bin/bash
grub> initrd /initramfs-4.18.0-553.8.1.el8_10.x86_64.img
grub> boot

이 사례에서는 (hd0,gpt2)가 XFS 파일시스템의 /boot 파티션이었다. 별도의 /boot 파티션을 GRUB의 읽기 대상으로 정했으므로 커널 경로를 /vmlinuz-...로 썼다. /boot가 별도 파티션이 아닌 환경에서는 경로가 달라질 수 있다. 디스크 번호, 커널 버전, 논리 볼륨 이름은 서버마다 확인해야 하며 RHEL의 공통 기본값이 아니다.

명령 이름도 부팅 환경에 따라 확인해야 한다. 이 글은 기록에 남은 linux와 initrd를 사용하지만, RHEL 8의 UEFI 부팅 항목에는 linuxefi와 initrdefi가 쓰이는 구성도 있다. 기존 부팅 항목과 사용 가능한 명령을 기준으로 판단해야 한다. RHEL 8 UEFI 부팅 항목

linux는 커널을 메모리에 적재하고 뒤의 인자를 커널 명령줄로 전달한다. initrd는 초기 사용자 공간에 쓸 이미지를 적재하며 linux 뒤에 실행한다. 마지막 boot에서 적재한 커널의 실행으로 넘어간다. 커널 파일을 골랐다는 사실과 운영체제가 실제로 시작됐다는 사실은 다른 단계다. GNU/Linux 수동 부팅

이름은 같지만 대상이 다른 두 root

여기서 중요한 구분은 set root와 커널 인자 root=다.

앞의 root를 설정해도 리눅스의 루트가 자동으로 정해지는 것은 아니다. 이 서버에서는 /boot와 실제 루트가 달랐고, 실제 루트는 논리 볼륨 관리자(LVM)가 관리하는 볼륨에 있었다. initramfs의 초기 사용자 공간에서 저장 장치를 준비하고 해당 볼륨을 활성화해야 실제 루트로 넘어갈 수 있다.

커널과 initramfs도 대응하는 조합을 골라야 한다. initramfs에는 초기 부팅에 필요한 드라이버와 도구가 들어간다. LVM 루트라면 장치 매퍼 지원뿐 아니라 볼륨을 찾고 활성화하는 도구와 설정도 필요하다. 단순히 ‘LVM 모듈 하나가 있으면 된다’고 설명할 수는 없다.

파일명에 적힌 버전이 맞는지 확인하는 것은 첫 점검이다. 이름이 맞아도 필요한 구성 요소가 빠졌거나 루트 대상이 잘못 지정돼 있으면 부팅은 실패할 수 있다. 반대로 부팅 실패가 곧 커널·initramfs 버전 불일치를 뜻하는 것도 아니다.

복구용 root 셸에서 변경 사항 되돌리기

init=/bin/bash는 실제 루트로 넘어간 뒤 실행할 init 프로그램을 Bash로 지정하려는 인자다. 일반적인 로그인 과정을 거치지 않는 복구용 셸을 얻기 위해 사용했다. initramfs 단계까지 생략한다는 뜻은 아니다. 리눅스 커널의 init 인자

RHEL의 rescue.target은 systemd가 제공하는 별도의 단일 사용자 복구 환경이다. init=/bin/bash와 같은 방식이 아니며, root 인증을 요구하는 구성에서는 인증 상태를 고려해야 한다. 다만 당시 rescue 모드의 인증도 동일한 원인으로 실패했는지까지 확인한 기록은 없다. 내가 실제 사용한 경로는 Bash를 init으로 지정하는 방식이었다. RHEL 8 복구 모드

커널 인자의 ro는 루트를 읽기 전용으로 마운트하도록 지정한다. 복구 셸에 도달한 뒤에는 실제 루트 파일시스템을 대상으로 다음 명령을 실행해 쓰기 가능 상태로 바꿨다.

mount -o remount,rw /

이후 OpenSSL을 이전 상태로 되돌려 root 접근을 복구했다. 당시 롤백에 사용한 패키지 명령과 대상 버전은 이 글에서 재현할 수 있을 만큼 남아 있지 않아 임의로 덧붙이지 않았다. 복구 셸은 평소의 서비스와 네트워크가 모두 올라온 환경이 아니므로, 필요한 파일과 마운트 상태도 함께 확인해야 한다.

복구 결과와 원인 판단의 경계

OpenSSL을 되돌린 뒤 root 접근이 가능해졌고, 재부팅에서도 정상적으로 올라왔다. grub.cfg를 별도로 재생성하지 않았다는 점도 당시 작업 기록의 일부다. 수동 부팅은 변경 사항을 되돌릴 환경에 도달하는 데 사용했다.

다만 이 결과만으로 OpenSSL이 GRUB 명령줄 진입까지 직접 유발했다고 결론 내릴 수는 없다. GRUB는 설치된 리눅스의 일반 사용자 공간보다 먼저 실행된다. 운영체제의 인증 라이브러리 문제와 부트로더의 설정·모듈 로딩 문제를 같은 경로로 묶으려면 추가 근거가 필요하다.

확인된 범위는 ‘업그레이드 직후 권한 획득이 막힘’, ‘재부팅 후 GRUB 명령줄에서 수동 부팅’, ‘롤백 후 권한과 정상 부팅 회복’이다. 실패 로그와 부팅 설정의 전후 비교가 없는 상태에서 두 증상의 관계까지 확정하지는 않는다. 복구가 성공한 것과 원인을 끝까지 규명한 것은 구분해서 남긴다.

학습

• 프롬프트와 부팅 단계를 먼저 확인한다. grub>, grub rescue>, initramfs 셸, 리눅스 root 셸은 사용할 수 있는 명령과 복구 대상이 다르다.
• 부팅 파일의 위치와 실제 루트 파일시스템을 구분한다. 이번에는 별도 /boot에서 커널을 읽고 LVM의 루트로 넘어갔다.
• 수동 부팅과 영구 설정 수리는 다른 작업이다. 한 번 부팅한 뒤에도 재부팅 결과와 설정 상태를 확인해야 한다.
• 정상화 결과로 미확인 원인을 채우지 않는다. 이번 기록에서는 롤백 뒤 회복한 사실까지 설명할 수 있다.
• 운영체제의 SSH가 올라오기 전에도 접근할 콘솔을 확보한다. 물리 콘솔, 원격 관리 콘솔, 가상 머신·클라우드의 콘솔 등 환경에 맞는 경로와 부팅 항목을 수정할 권한을 미리 확인해야 한다.