CentOS를 새로 구성한 뒤 root 로그인이나 sudo 권한이 작동하지 않을 때는 설치 이미지보다 계정 생성 방식, 부팅 모드, SELinux 정책, 파일 소유권을 먼저 확인해야 합니다. 데이터 보존 여부를 점검한 뒤 디스크 구성부터 관리자 계정 복구까지 단계별로 처리합니다.
루트 로그인이 막힌 CentOS, 초기 설치 뒤 관리자 권한을 되살리는 순서
설치는 끝났는데 관리자 명령마다 권한 거부가 나타나면, 설치 실패와 계정 설정 문제를 분리해서 봐야 합니다. root 비밀번호를 만들었는지, 일반 계정을 생성했는지, 그 계정이 wheel 그룹에 들어갔는지에 따라 복구 경로가 달라집니다. SSH로만 접속을 시도하다가 막힌 경우에는 root 계정 자체의 문제인지, 원격 직접 로그인을 막아 둔 정책인지도 구분해야 합니다. 디스크를 비운 뒤 다시 구성하는 작업은 기존 데이터와 부팅 정보까지 영향을 줄 수 있으므로, 설치 화면부터 되돌아가기 전 현재 상태를 먼저 기록하는 편이 안전합니다. 부팅은 되지만 권한 구조가 불명확하거나 서비스 접근 오류가 겹쳤다면 동네형컴퓨터 010-6833-8119 로 증상 화면과 접속 가능 여부를 함께 알려주시면 점검 범위를 정리할 수 있습니다. 핵심은 root 잠금, sudo 설정, SELinux 정책, 부팅 구성을 한 문제로 뭉뚱그리지 않는 것입니다.
root 계정과 sudo 권한이 함께 막히는 설치 직후 상황
설치 직후 관리자 권한이 안 된다고 해서 root 계정이 항상 고장 난 것은 아닙니다. 먼저 콘솔에서 root 비밀번호가 설정됐는지 확인하고, 일반 사용자 계정으로 로그인할 수 있는지 살핍니다. 일반 계정 로그인까지 가능하다면 해당 계정이 wheel 그룹 또는 sudo 사용 그룹에 속하는지 확인하는 것이 다음 순서입니다.
sudo 권한은 단순히 비밀번호를 여러 번 입력한다고 살아나지 않습니다. 권한이 있는 계정으로 id 명령을 실행해 그룹 구성을 확인하고, 필요하면 관리자 권한으로 계정을 wheel 그룹에 등록합니다. 이후 visudo로 /etc/sudoers 및 포함 파일의 문법을 검사해야 합니다. 편집기로 파일을 바로 수정하다가 문법 오류가 생기면, 모든 sudo 실행이 막힐 수 있기 때문입니다.
| 보이는 증상 | 우선 확인할 지점 | 검증 방법 |
|---|---|---|
| root 콘솔 로그인이 거부됨 | 비밀번호 설정, 계정 잠금 상태 | 콘솔·복구 환경에서 계정 상태 확인 |
| 일반 계정에서 sudo 가 거부됨 | wheel 그룹, sudoers 문법 | 그룹 조회 후 visudo 검사 |
| SSH에서만 root 접속 불가 | SSH 인증 방식과 직접 로그인 정책 | PermitRootLogin 설정 확인 |
특히 /etc/ssh/sshd_config의 PermitRootLogin은 root 의 원격 직접 접속 가능 여부에 영향을 줍니다. 콘솔 root 로그인과 SSH root 로그인은 같은 결과가 아닐 수 있습니다. 따라서 SSH 정책을 풀기 전에 일반 계정으로 접속한 뒤 sudo 를 쓰는 운영 방식이 가능한지부터 판단하는 편이 좋습니다. 숭인동 centos 재설치(포맷) 초기화처럼 설치부터 다시 검토하는 상황이라도, 권한 문제만 남은 상태라면 디스크를 다시 지우기보다 계정 구조부터 복구하는 쪽이 손실을 줄일 수 있습니다.
SELinux 때문에 서비스 접근이 거부될 때 확인할 항목
계정에 sudo 권한이 정상인데 웹 서비스, 데이터 디렉터리, 업로드 경로만 접근 거부를 낸다면 파일 권한과 SELinux 를 따로 봐야 합니다. 파일 소유자와 읽기·쓰기·실행 권한이 맞더라도, SELinux 가 Enforcing 상태에서 보안 컨텍스트가 어긋나면 서비스 프로세스는 해당 파일을 사용할 수 없습니다.
이때 가장 먼저 할 일은 SELinux 를 무조건 끄는 것이 아닙니다. 현재 상태를 확인하고, 감사 로그에 어떤 접근이 차단됐는지 확인한 다음 파일의 소유권·일반 권한·보안 컨텍스트를 순서대로 비교합니다. 설치 후 파일을 다른 디스크에서 복사했거나 홈 디렉터리와 서비스 경로를 수동으로 옮긴 경우에는 컨텍스트가 원래 경로와 다르게 붙어 있을 수 있습니다.
서비스 계정이 접근해야 하는 경로만 대상으로 컨텍스트 복구와 정책 확인을 진행하면, 보안 범위를 불필요하게 낮추지 않고 문제 지점을 좁힐 수 있습니다. 권한 숫자만 바꾸거나 모든 경로에 과도한 권한을 부여하는 방식은 잠시 동작해 보여도 이후 업데이트나 서비스 재시작 때 다른 오류를 만들 수 있습니다.
초기화 전후에 놓치기 쉬운 부팅과 계정 검증
디스크 초기화는 사용자 데이터만 지우는 작업이 아닙니다. 대상 파티션의 기존 부트 정보와 계정 정보, 홈 디렉터리도 함께 사라질 수 있습니다. 별도 데이터 파티션이 있는지, 백업이 완료됐는지, 완전 초기화가 필요한지부터 결정해야 하며 설치 대상 디스크를 잘못 선택하지 않도록 용량과 연결 상태를 확인해야 합니다.
UEFI 장비라면 EFI System Partition 생성 여부와 부팅 항목 등록 상태가 중요합니다. Legacy BIOS 방식으로 쓰던 장비를 다른 방식으로 설치하면 재부팅 뒤 운영체제를 찾지 못할 수 있습니다. 설치 전에 기존 부팅 방식, 디스크 순서, RAID 또는 별도 데이터 디스크 유무를 기록해 두면 복구 판단이 쉬워집니다.
설치가 끝났다고 바로 인수하지 말고 재부팅 뒤 세 가지를 나누어 시험합니다. 첫째, 콘솔에서 일반 계정과 root 관련 설정이 의도대로 동작하는지 확인합니다. 둘째, 일반 계정으로 sudo 명령을 실행해 관리자 권한 상승이 되는지 확인합니다. 셋째, 네트워크가 필요한 환경이라면 SSH 접속과 서비스 기동을 별도로 점검합니다. 이 순서라야 부팅 문제와 원격 접속 정책 문제를 혼동하지 않습니다.
방문 작업 시간만 간단히 맞추기
숭인동 현장 작업은 백업 여부, 장비 전원 상태, 설치 매체 부팅 필요성을 기준으로 일정을 조율합니다. 출장 작업은 09:00~18:00 에 서울·경기·인천·세종에서 가능하며, 원격 점검은 새벽 시간을 제외하고 정상 부팅과 네트워크 연결이 되는 장비를 우선 검토합니다. 부팅 불가, 디스크 교체, 설치 USB 부팅이 필요한 경우에는 현장 대응이 적합합니다.
권한 오류가 반복되기 전에 남길 정보
root 로그인이 거부되거나 sudo 비밀번호 입력이 반복되고, 서비스까지 권한 오류를 낸다면 오류 화면을 남겨 두는 것이 좋습니다. CentOS 버전, 설치 매체 종류, 디스크 구성, UEFI 또는 Legacy 여부, 현재 접속 방식도 함께 정리하면 계정 문제인지 설치 구조 문제인지 판단하는 시간이 줄어듭니다.
새 설치 뒤 root 잠금과 sudoers 오류를 분리해 확인하면 불필요한 재설치를 피할 수 있습니다. 반대로 디스크 초기화가 꼭 필요한 경우에는 데이터 보존 범위와 부팅 방식을 먼저 확정한 뒤 진행해야 합니다. 숭인동 centos 재설치(포맷) 초기화를 고려 중이라면, 단순 로그인 실패 화면만으로 포맷을 결정하기보다 복구 가능한 관리자 계정이 남아 있는지부터 확인하는 편이 낫습니다.
마지막으로 재부팅 전에는 콘솔 로그인, sudo 실행, SSH 접속, 서비스 접근을 각각 검증해야 합니다. 이 네 가지가 따로 통과해야 설치 완료 후 다시 관리자 권한이 막히는 상황을 줄일 수 있습니다. 점검 또는 작업 문의는 동네형컴퓨터 010-6833-8119, 안내 페이지는 https://udns.kr/에서 확인할 수 있습니다.
자주 묻는 질문
CentOS를 새로 설치하면 기존 사용자 계정도 모두 사라지나요?
초기화한 파티션에 있던 계정 정보와 홈 디렉터리는 함께 삭제될 수 있습니다. 별도 데이터 파티션이 있는지와 백업 완료 여부를 먼저 확인해야 합니다.
root 로그인이 안 되면 sudo 권한으로 복구할 수 있나요?
sudo 권한이 있는 일반 계정이 남아 있다면 root 비밀번호, 그룹 구성, SSH 설정을 점검할 수 있습니다. sudo 권한도 없다면 콘솔 또는 복구 환경 접근이 필요할 수 있습니다.
원격으로 관리자 권한 문제를 처리할 수 있나요?
운영체제가 정상 부팅되고 접속 가능한 일반 계정 또는 콘솔 접근 수단이 있어야 합니다. 부팅 불가, 디스크 교체, 설치 매체 부팅이 필요한 경우에는 현장 작업이 더 적합합니다.