sudo 권한 문제 해결: Linux ‘is not in the sudoers file’ 오류 디버깅

리눅스 서버를 만지다 보면 한 번쯤은 sudo 권한 문제 해결 때문에 손이 멈추는 순간이 옵니다. 특히 <code>user is not in the sudoers file. This incident will be reported. 같은 문구를 처음 보면, 저도 그랬지만 순간 식은땀이 나더라고요. 분명 계정은 있는데 명령이 안 되고, root(최고관리자 계정)로 바로 붙을 수도 없는 상황이면 더 난감합니다. 홈랩에서 새 계정을 만들고 권한을 넘기다가, 회사에서는 운영 서버에서 계정 정책을 정리하다가 이런 일을 꽤 자주 겪었거든요.

이번 글에서는 sudoers 파일 오류를 중심으로, 리눅스 권한(사용자 권한 체계), 권한 상승(상위 권한 획득), 그리고 sudo 디버깅 과정을 경험담 섞어서 정리해보겠습니다. 단순히 명령어 몇 줄 던지고 끝내는 게 아니라, 왜 이런 문제가 생기는지부터 안전하게 고치는 방법까지 같이 보시죠.

사용자, 그룹, sudo, root 계정의 관계를 한눈에 보여주는 개요 이미지입니다.

1. 왜 ‘is not in the sudoers file’ 오류가 생길까요?

쉽게 말해, sudo(관리자 권한으로 명령 실행)는 아무나 쓸 수 있는 도구가 아닙니다. 시스템은 ‘이 사용자가 관리자 명령을 실행해도 되는가?’를 /etc/sudoers 파일과 관련 설정 디렉터리에서 확인합니다. 여기서 허용되지 않은 계정이면 바로 거부하는 거죠.

처음엔 이게 뭔가 싶었는데, 실제로 써보니까 원인은 생각보다 단순한 경우가 많았습니다.

• 사용자가 아예 sudo 허용 그룹에 속해 있지 않은 경우
• /etc/sudoers 문법이 깨진 경우
• /etc/sudoers.d/ 아래 추가 설정이 잘못된 경우
• 배포판별 기본 관리자 그룹 이름을 착각한 경우
• SSH로 접속한 계정과 수정한 계정이 다른 경우

여기서 중요한 포인트가 있습니다. sudo 권한 문제 해결은 단순히 파일 하나 고치는 작업이 아니라, 계정, 그룹, PAM(인증 모듈), 로그까지 같이 봐야 정확하거든요.

2. sudoers 파일과 관리자 그룹, 개념을 먼저 잡아보겠습니다

제가 초반에 가장 헷갈렸던 부분이 이겁니다. ‘sudoers에 직접 사용자 넣으면 끝 아닌가요?’ 맞습니다. 그렇게도 할 수 있죠. 근데 운영 환경에서는 보통 그룹 기반 관리가 훨씬 낫더라고요. 사람마다 계정을 직접 적기 시작하면 나중에 정리하기가 정말 힘들어집니다.

2-1. sudoers 파일 오류가 의미하는 것

/etc/sudoers는 sudo 정책의 핵심 파일입니다. 누가 어떤 호스트에서 어떤 사용자로 어떤 명령을 실행할 수 있는지 정의하죠. 문법이 정말 엄격해서 공백 하나, 줄바꿈 잘못, 항목 하나만 틀어도 전체가 작동 안 하더라고요. 그래서 이 파일은 보통 직접 편집하지 않고 visudo로 다룹니다.

2-2. 배포판별 대표 관리자 그룹

이 차이를 모르고 Ubuntu에서 wheel만 찾거나, 반대로 Rocky Linux에서 sudo 그룹만 찾다가 시간을 꽤 썼습니다. 삽질 좀 했습니다 ㅎㅎ

3. sudo 권한 문제 해결 전, 먼저 확인할 체크리스트

문제 생기면 바로 파일 열지 마시고요, 아래 순서로 확인하면 훨씬 빨리 풀립니다. 실제 현업에서도 저는 이 순서대로 보는 편입니다.

1. 현재 로그인한 사용자가 누구인지 확인합니다.
2. 그 사용자가 어떤 그룹에 속해 있는지 봅니다.
3. /etc/sudoers와 /etc/sudoers.d/에 허용 규칙이 있는지 확인합니다.
4. 문법 오류가 없는지 검사합니다.
5. 인증 로그와 보안 로그를 확인합니다.

3-1. 현재 사용자와 그룹 확인

whoami
id
groups

예를 들어 id 결과에서 sudo나 wheel 그룹이 보이지 않으면, 거의 방향이 잡힌 겁니다. 사용자는 있는데 관리자 그룹에 빠져 있는 거죠.

3-2. sudo 설정 파일 확인

sudo -l
sudo -V
ls -l /etc/sudoers /etc/sudoers.d
sudo cat /etc/sudoers

다만 이미 sudo가 막혀있으면 sudo cat은 실행이 안 됩니다. 이럴 때는 root 계정으로 직접 로그인하거나, 클라우드/가상화 콘솔, 복구 모드(복구 부팅 환경)로 들어가야 합니다.

사용자 그룹과 sudo 설정 파일을 점검하는 실전 터미널 흐름을 보여주는 이미지입니다.

4. 실전 구현: 가장 안전하게 sudo 권한 복구하는 방법

이제 본격적으로 고쳐보겠습니다. 여기서는 배포판에 따라 나눠서 설명드릴게요. 제가 직접 해보니, 계정 하나를 급하게 복구할 때는 사용자 개별 추가보다 그룹 추가가 훨씬 덜 꼬입니다.

4-1. Ubuntu/Debian 계열에서 사용자에게 sudo 권한 주기

su -
usermod -aG sudo username
id username

username 자리에 실제 계정을 넣으면 됩니다. 여기서 -aG를 빼먹으면 기존 그룹이 날아갈 수 있으니 조심하셔야 합니다. 저도 예전에 급하게 치다가 그룹 구성이 꼬인 적이 있었거든요.

4-2. RHEL/CentOS/Rocky/AlmaLinux 계열에서 권한 주기

su -
usermod -aG wheel username
id username

이 계열은 보통 wheel 그룹을 관리자 그룹으로 씁니다. 다만 /etc/sudoers에 해당 그룹 허용 줄이 주석 처리되어 있으면, 그룹에 넣어도 sudo가 안 되거든요.

4-3. sudoers에 그룹 허용 규칙이 있는지 확인

visudo

대표적으로 아래 같은 줄을 확인합니다.

%sudo   ALL=(ALL:ALL) ALL
%wheel  ALL=(ALL:ALL) ALL

둘 중 어떤 줄을 쓸지는 배포판과 운영 정책에 따라 다릅니다. 둘 다 열어두는 환경도 있지만, 보안 기준이 엄격한 곳에서는 하나만 씁니다.

4-4. 개별 사용자에게만 제한적으로 허용하고 싶을 때

운영 서버에서는 전역 파일보다 /etc/sudoers.d/를 쓰는 게 관리가 편해집니다.

visudo -f /etc/sudoers.d/username

username ALL=(ALL:ALL) ALL

혹은 특정 명령만 허용할 수도 있습니다.

username ALL=(ALL:ALL) /usr/bin/systemctl restart nginx, /usr/bin/journalctl

이 방식은 최소 권한 원칙(꼭 필요한 권한만 부여)에 잘 맞습니다. DevOps나 운영 자동화 계정 설계할 때 특히 유용하더라고요.

5. ⚠️ 실제로 많이 겪는 sudo 디버깅 포인트

여기서부터가 진짜 중요합니다. 단순히 그룹만 맞춘다고 다 끝나지 않거든요. 제가 현장에서 자주 본 케이스를 정리해보겠습니다.

5-1. visudo 대신 직접 편집하다가 문법 깨짐

가장 위험한 케이스입니다. vim /etc/sudoers로 직접 만졌다가 문법이 깨지면, sudo 자체가 작동하지 않을 수 있습니다.

visudo -c

이 명령으로 문법 검사를 먼저 해보세요. 여러 조각 파일까지 같이 확인하고 싶으면 아래처럼 봅니다.

visudo -c -f /etc/sudoers

문법 오류가 나오면 해당 줄 번호를 보고 수정하면 됩니다. 드디어 됐다! 하는 순간이 보통 여기서 오더라고요.

5-2. 그룹 추가 후에도 바로 적용되지 않음

사용자를 그룹에 넣으면 현재 세션에는 바로 안 먹는 경우가 있습니다. 이럴 땐 로그아웃 후 다시 로그인하거나 새 SSH 세션으로 붙어야 합니다.

su - username
id
sudo -l

저도 처음엔 설정이 안 먹은 줄 알고 파일만 몇 번 다시 봤었는데, 그냥 세션 재접속 문제였던 적이 많았습니다.

5-3. /etc/sudoers.d/ 파일 권한 문제

sudo는 포함 파일의 권한도 엄격하게 봅니다. 너무 느슨하면 무시되거나 경고가 납니다.

ls -l /etc/sudoers.d
chmod 440 /etc/sudoers.d/username
chown root:root /etc/sudoers.d/username

소유자 root, 권한 440 패턴은 꼭 기억해두시면 좋습니다.

5-4. 로그로 원인 확인하기

로그를 보면 생각보다 힌트가 많이 나옵니다.

journalctl -xe
journalctl _COMM=sudo
grep -i sudo /var/log/auth.log
grep -i sudo /var/log/secure

Debian/Ubuntu 계열은 /var/log/auth.log, RHEL 계열은 /var/log/secure를 보는 경우가 많습니다. 인증 실패인지, 정책 거부인지, 문법 오류인지가 여기서 갈립니다.

문법 검사, 권한 확인, 로그 분석으로 이어지는 sudo 디버깅 흐름을 정리한 이미지입니다.

6. sudoers 파일 오류를 복구 모드에서 고친 경험

한 번은 홈랩 VM에서 /etc/sudoers를 잘못 만져서 일반 계정도 안 되고 sudo도 안 되는 상황이 있었습니다. 사실 이런 상황 오면 좀 당황스럽더라고요. 그런데 순서만 알면 복구는 가능합니다.

1. 하이퍼바이저 콘솔 또는 클라우드 시리얼 콘솔로 접속합니다.
2. 복구 모드나 단일 사용자 모드(최소 환경 부팅)로 진입합니다.
3. 루트 셸에서 visudo로 문법을 수정합니다.
4. 필요하면 사용자를 관리자 그룹에 다시 추가합니다.
5. 재부팅 후 일반 세션에서 sudo -l로 검증합니다.

정말 핵심은 하나입니다. sudoers는 항상 visudo로 수정. 이 원칙만 지켜도 장애 확률이 확 줄어듭니다.

7. 검증: 수정 후 무엇을 확인해야 할까요?

설정 바꿨으면 끝이 아니라 검증까지 해야 합니다. 특히 운영 서버에서는 ‘명령이 한 번 됐다’ 정도로 끝내면 나중에 다시 문제 생길 수 있거든요.

7-1. 기본 검증 명령

id
sudo -l
sudo whoami
sudo systemctl status sshd

정상이라면 sudo whoami 결과가 root로 나옵니다. 그리고 sudo -l에서 허용된 정책 목록이 보여야 합니다.

7-2. 확인 포인트 요약

권한 복구가 끝난 뒤 실제 검증이 성공한 상태를 보여주는 결과 이미지입니다.

8. 자주 묻는 질문과 제가 추천하는 운영 습관

8-1. 사용자별 직접 등록과 그룹 등록, 뭐가 더 나을까요?

개인적으로는 그룹 등록을 먼저 추천합니다. 사람이 바뀌어도 정책은 유지되고, 계정 추가/삭제가 간단해집니다. 예외적인 서버만 개별 파일로 빼는 방식이 관리가 편하더라고요.

8-2. 비밀번호 없이 sudo를 허용해도 될까요?

자동화 계정에서는 쓰는 경우가 있지만, 일반 사용자 계정에는 신중해야 합니다. 예를 들면 아래처럼 NOPASSWD를 줄 수는 있습니다.

username ALL=(ALL:ALL) NOPASSWD: /usr/bin/systemctl restart nginx

다만 범위를 넓게 주면 사고가 커질 수 있습니다. 그래서 저는 특정 명령만 허용하는 식으로 씁니다.

8-3. 다음에 비슷한 문제를 줄이려면?

• /etc/sudoers 직접 수정 대신 visudo 사용
• 정책은 가능하면 /etc/sudoers.d/로 분리
• 배포판별 관리자 그룹 이름 확인
• 변경 후 visudo -c와 sudo -l로 검증
• 운영 변경 이력은 문서화

이전 글에서 다뤘던 리눅스 계정 관리 내용이 있다면 같이 묶어서 보시면 더 이해가 잘 됩니다. 다음 글에서는 PAM 정책과 SSH 접근 제어도 한 번 정리해볼 예정입니다.

sudo 권한 문제 해결 절차와 운영 체크리스트를 한 장으로 정리한 요약 이미지입니다.

9. 마무리: sudo 권한 문제 해결은 순서만 알면 생각보다 단순합니다

sudo 권한 문제 해결은 막상 닥치면 복잡해 보이지만, 실제로는 사용자 확인, 그룹 확인, sudoers 문법 확인, 로그 확인 이 네 가지 축으로 정리됩니다. 저도 처음엔 계정이 망가진 줄 알고 겁먹었는데, 하나씩 따라가 보니 대부분은 그룹 누락이나 설정 파일 문법 문제였습니다.

정리해보면 이렇습니다. sudoers 파일 오류가 보이면 무작정 재설치할 일이 아니라, 현재 계정 상태와 정책 파일부터 차분히 보시면 됩니다. 특히 visudo, visudo -c, id, sudo -l 이 네 개는 거의 필수 도구라고 보셔도 됩니다. 혹시 지금 같은 오류 때문에 막혀 계신다면, 이 글 순서대로 한 단계씩 점검해보세요. 생각보다 빨리 길이 보일 겁니다. 🎉