13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] sudoers

  • [Linux] sudo 권한 문제 해결: ‘is not in the sudoers file’ 오류 및 권한 설정 디버깅

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

    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 권한 구조 개요 이미지

    사용자, 그룹, 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, Debian sudo 사용자를 sudo 그룹에 넣는 방식이 표준입니다.
    CentOS, RHEL, Rocky, AlmaLinux wheel wheel 그룹에 sudo 허용 규칙을 두는 경우가 많습니다.
    기타 커스텀 환경 조직 정책별 상이 /etc/sudoers.d/로 따로 관리하기도 합니다.

    이 차이를 모르고 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 권한 문제 해결 과정에서 id와 groups, sudoers 설정을 점검하는 터미널 이미지

    사용자 그룹과 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를 보는 경우가 많습니다. 인증 실패인지, 정책 거부인지, 문법 오류인지가 여기서 갈립니다.

    sudoers 파일 오류와 로그 분석을 통한 sudo 디버깅 흐름 이미지

    문법 검사, 권한 확인, 로그 분석으로 이어지는 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. 확인 포인트 요약

    확인 항목 정상 상태 이상 징후
    사용자 그룹 sudo 또는 wheel 포함 관리자 그룹 누락
    sudoers 문법 visudo -c 통과 syntax error
    포함 파일 권한 root:root, 440 권한 과다 또는 소유자 불일치
    실행 테스트 sudo whoami 성공 비밀번호 거부 또는 정책 거부
    sudo 권한 문제 해결 후 sudo whoami와 sudo -l 검증 결과 이미지

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

    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 권한 문제 해결 체크리스트와 운영 베스트 프랙티스 요약 이미지

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

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

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

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

  • [Linux] Linux 사용자 관리: sudo 권한부터 계정 관리까지 1년 실전 가이드

    [Linux] Linux 사용자 관리: sudo 권한부터 계정 관리까지 1년 실전 가이드

    [Linux] Linux 사용자 관리: sudo 권한부터 계정 관리까지 1년 실전 가이드

    홈랩을 오래 굴리다 보면 결국 제일 자주 만지는 영역이 Linux 사용자 관리더라고요. 처음에는 계정 하나 만들고 <code>sudo만 붙여주면 끝인 줄 알았는데, 실제로 1년 정도 운영해보니 그게 시작이었습니다. 누가 어떤 권한을 가져야 하는지, 비밀번호 정책은 어디까지 강하게 가져갈지, SSH(Secure Shell, 원격 접속) 접근은 어떻게 나눌지 같은 문제가 계속 나오거든요. 특히 여러 대의 서버를 동시에 관리하면 작은 실수가 바로 보안 이슈로 이어질 수 있어서, 이 부분은 초반에 습관을 잘 잡는 게 정말 중요합니다.

    저도 처음엔 루트(root, 최고 관리자 계정)로 바로 접속해서 작업하던 시기가 있었는데요. 편하긴 한데, 실수 한 번이면 복구가 꽤 피곤했습니다. 그래서 지난 1년 동안은 일반 사용자 계정 기반으로 운영하고, 필요한 작업만 sudo로 올리는 방식으로 정리해봤습니다. 실제로 써보니까 관리 포인트가 명확해지고, 문제 추적도 쉬워지더라고요. 이번 글에서는 제가 직접 해보며 정리한 사용자 관리 기준, sudo 권한 설정 방법, 그리고 계정 운영할 때 자주 터지는 문제까지 한 번에 묶어서 공유해보겠습니다.

    여러 대의 Linux 서버에서 사용자, 그룹, sudo 권한, SSH 접근 흐름이 어떻게 연결되는지 보여주는 개요 이미지입니다.

    1. 왜 Linux 사용자 관리가 생각보다 중요한가

    쉽게 말해 Linux 사용자 관리는 “누가, 어디까지, 어떤 방식으로 시스템을 만질 수 있느냐”를 정하는 일입니다. 서버가 한 대일 때는 체감이 덜할 수 있는데, 두 대 세 대 넘어가고 NAS(Network Attached Storage, 네트워크 저장소)나 컨테이너 호스트까지 붙기 시작하면 이야기가 달라집니다. 계정을 아무 생각 없이 늘리면, 나중에 누가 어떤 변경을 했는지 찾기 어려워집니다.

    • 책임 추적(Accountability, 작업 책임 추적)이 쉬워집니다.
    • 최소 권한 원칙(Principle of Least Privilege, 필요한 만큼만 권한 부여)을 적용할 수 있습니다.
    • 루트 계정 직접 사용을 줄여서 사고 범위를 제한할 수 있습니다.
    • 퇴사자 계정, 테스트 계정, 임시 계정을 정리하기 쉬워집니다.

    여기서 중요한 포인트! Linux는 기본적으로 강력한 멀티유저(multi-user, 다중 사용자) 시스템입니다. 그런데 운영자가 그 특성을 제대로 활용하지 않으면, 그냥 “다들 sudo 되는 단일 사용자 환경”처럼 굴러가 버리더라고요. 저도 한동안 그렇게 썼었는데, 나중에 계정 관리가 꼬이니까 정리가 꽤 힘들었습니다.

    2. Linux 사용자 관리의 핵심 개념 정리

    저도 처음엔 헷갈렸는데, 아래 네 가지만 명확히 잡으면 절반은 끝입니다.

    2-1. 사용자(User)와 그룹(Group)

    사용자(User, 개별 계정)는 실제 로그인 주체이고, 그룹(Group, 권한 묶음)은 여러 사용자에게 공통 권한을 부여할 때 씁니다. 보통 운영은 사용자에게 직접 권한을 덕지덕지 붙이는 것보다, 그룹 설계를 먼저 하고 사용자를 그룹에 넣는 쪽이 관리가 훨씬 편하더라고요.

    2-2. sudo 권한

    sudo는 superuser do의 약자로, 일반 계정이 관리자 권한으로 특정 명령을 실행할 수 있게 해줍니다. 즉, 항상 루트로 로그인하지 않아도 필요한 순간에만 권한을 올릴 수 있는 거죠. 실제로 써보니까 이 방식이 사고 범위를 줄이는 데 확실히 도움이 됐습니다.

    2-3. 인증(Authentication)과 인가(Authorization)

    인증은 “누구냐”를 확인하는 것이고, 인가는 “무엇을 할 수 있느냐”를 정하는 겁니다. SSH 키 로그인, 비밀번호, MFA(Multi-Factor Authentication, 다중 인증) 같은 건 인증 쪽이고, sudoers 설정은 인가 쪽에 가깝습니다.

    2-4. 관련 파일

    파일 역할 실무 포인트
    /etc/passwd 사용자 기본 정보 로그인 셸, 홈 디렉터리 확인
    /etc/shadow 비밀번호 해시 저장 권한 제한 필수
    /etc/group 그룹 정보 권한 설계 시 자주 확인
    /etc/sudoers sudo 정책 직접 수정 시 반드시 visudo 사용
    /etc/sudoers.d/ sudo 분리 설정 서버 역할별 관리에 유리

    사실 Linux 계정 관리에서 제일 중요한 건 명령어를 많이 아는 것보다, 정책을 일관되게 가져가는 것입니다. 같은 팀인데 서버마다 sudo 정책이 다르면, 그게 더 큰 장애 포인트가 되더라고요.

    3. 실전 구현: 계정 생성부터 그룹 설계까지

    제가 홈랩에서 가장 많이 쓰는 방식은 “개인 사용자 계정 + 역할 그룹 + 필요한 sudo만 부여” 구조입니다. 아래 예시는 Debian/Ubuntu 계열에서도 이해하기 쉽고, 다른 배포판에서도 거의 같은 개념으로 적용됩니다.

    1. 관리용 그룹을 먼저 만듭니다.
    2. 사용자 계정을 생성하고 홈 디렉터리를 함께 준비합니다.
    3. 필요한 그룹에 사용자를 추가합니다.
    4. SSH 키 인증을 붙입니다.
    5. 마지막으로 sudo 정책을 분리 파일로 관리합니다.

    3-1. 사용자 생성

    sudo adduser minsu
    sudo passwd minsu
    id minsu
    getent passwd minsu

    adduser는 대화형으로 홈 디렉터리와 기본 설정을 함께 잡아줘서 초반엔 편합니다. 반대로 자동화가 필요할 때는 useradd를 더 자주 쓰게 되더라고요.

    3-2. 그룹 기반으로 권한 묶기

    sudo groupadd ops
    sudo usermod -aG ops minsu
    id minsu
    getent group ops

    여기서 -aG 옵션을 빼먹으면 기존 보조 그룹이 날아갈 수 있습니다. 저 이거 한 번 놓쳐서 기존 접근 권한이 꼬인 적이 있었는데요. 드디어 됐다 싶었는데, 다른 작업 권한이 사라져 있더라고요. 그 뒤로는 id 사용자명으로 바로 검증하는 습관을 붙였습니다.

    Linux 사용자 관리와 sudo 권한 설정 흐름을 보여주는 이미지

    사용자 생성, 그룹 추가, sudoers.d 정책 분리까지 이어지는 실전 구성 흐름을 보여주는 이미지입니다.

    3-3. SSH 디렉터리와 권한 정리

    sudo mkdir -p /home/minsu/.ssh
    sudo chmod 700 /home/minsu/.ssh
    sudo touch /home/minsu/.ssh/authorized_keys
    sudo chmod 600 /home/minsu/.ssh/authorized_keys
    sudo chown -R minsu:minsu /home/minsu/.ssh

    SSH 키 로그인은 보안 측면에서 거의 기본값처럼 가져가는 게 좋습니다. 특히 외부에서 접속하는 서버라면 비밀번호 로그인만 믿고 가는 건 꽤 불안하거든요. 혹시 이런 경험 있으신가요? 키는 넣었는데 접속이 안 돼서 한참 헤매는 경우요. 대부분은 파일 권한이나 소유권 문제였습니다.

    4. sudo 권한 설정: 편하게 쓰되 넓게 주지는 않기

    sudo 권한은 편리하지만, 잘못 주면 사실상 루트와 다를 게 없어집니다. 그래서 저는 요즘 /etc/sudoers를 직접 건드리기보다 /etc/sudoers.d/ 아래에 역할별 파일을 나눠서 관리합니다. 이게 나중에 보기 훨씬 좋고, 변경 이력 추적도 편하더라고요.

    4-1. visudo로 안전하게 편집

    sudo visudo -f /etc/sudoers.d/ops

    예시 파일은 이렇게 구성할 수 있습니다.

    %ops ALL=(ALL:ALL) ALL

    이 설정은 ops 그룹 사용자에게 모든 명령에 대한 sudo 실행 권한을 주는 거거든요. 홈랩이나 소규모 환경에선 현실적인 출발점이긴 한데, 실제 운영에서는 더 좁히는 게 좋습니다.

    4-2. 특정 명령만 허용하는 방식

    Cmnd_Alias SERVICE_MGMT = /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx
    %ops ALL=(root) SERVICE_MGMT

    처음엔 이런 세분화가 좀 귀찮았습니다. 근데 실제로 써보니까 “누구나 뭐든지 sudo 가능” 상태보다 훨씬 안정적이더라고요. 특히 여러 사람이 함께 관리하는 환경에서는 이 차이가 큽니다. 쉽게 말해, sudo는 켜고 끄는 스위치가 아니라 정교하게 나눠야 하는 운영 정책에 가깝습니다.

    4-3. 비밀번호 요구 정책도 점검

    Defaults logfile=/var/log/sudo.log
    Defaults lecture=once

    서버마다 필요는 다르겠지만, 누가 어떤 sudo 명령을 썼는지 남기고 싶다면 로그 정책도 함께 보는 게 좋습니다. 나중에 문제 생겼을 때 이 로그가 꽤 유용합니다. 이거 진짜 편하더라고요.

    5. 계정 관리 운영 팁: 1년 써보니 결국 정리 습관이 남습니다

    계정 관리는 만들 때보다 치울 때 실력이 드러납니다. 테스트 계정, 임시 외주 계정, 스크립트용 서비스 계정(service account, 서비스 전용 계정)이 뒤섞이기 시작하면 금방 지저분해집니다. 제가 1년 동안 정리하면서 체감한 운영 팁은 아래와 같습니다.

    • 개인 계정과 서비스 계정을 섞지 않습니다.
    • 공용 계정을 최소화합니다. 가능하면 개인 계정 기반으로 갑니다.
    • sudo 권한은 그룹 단위로 관리합니다.
    • 서버 접속 방식은 SSH 키 중심으로 통일합니다.
    • 퇴역 계정은 잠금(lock) 후 일정 기간 뒤 삭제하는 식으로 단계적으로 정리합니다.

    5-1. 계정 잠금과 만료 처리

    sudo passwd -l minsu
    sudo usermod -L minsu
    sudo chage -l minsu

    즉시 삭제보다 잠금부터 거는 이유는, 혹시 남아 있는 프로세스나 파일 소유권 이슈를 확인할 시간이 필요해서입니다. 처음엔 저도 바로 삭제했었는데, 나중에 cron(Cron, 예약 작업)이나 백업 스크립트에서 참조 중인 경우가 있더라고요.

    5-2. 정말 삭제할 때

    sudo userdel -r minsu

    단, -r 옵션은 홈 디렉터리까지 지우기 때문에 신중해야 합니다. 여기서 중요한 포인트! 삭제 전에 파일 소유권 검색은 꼭 한 번 해보세요.

    sudo find / -user minsu 2>/dev/null | head

    6. ⚠️ 실제로 많이 겪는 문제와 해결법

    이 섹션은 정말 경험담 위주입니다. 제가 직접 해보니, Linux 사용자 관리에서 막히는 포인트는 대체로 비슷했습니다.

    6-1. sudo가 안 되는 경우

    원인은 보통 세 가지였습니다.

    1. 사용자가 올바른 그룹에 들어가 있지 않음
    2. /etc/sudoers.d/ 파일 권한이나 문법 오류
    3. 새 그룹 적용 전에 세션 재로그인 안 함
    id minsu
    sudo visudo -c
    ls -l /etc/sudoers.d/
    newgrp ops

    visudo -c로 문법 검사를 먼저 해보면 생각보다 빨리 원인을 찾습니다. 저도 sudoers 문법 한 글자 잘못 넣고 한참 헤맨 적이 있었는데, 그때 깨달았습니다. sudo 설정은 “될 것 같은데 안 되는” 상태가 제일 사람 지치게 하더라고요.

    6-2. SSH 키는 맞는데 로그인 실패

    대부분은 권한 문제였습니다.

    • ~/.ssh 권한이 너무 넓음
    • authorized_keys 소유자가 다름
    • 홈 디렉터리 권한이 과하게 열려 있음

    이럴 때는 계정만 보지 말고 상위 디렉터리까지 같이 확인해야 합니다.

    6-3. 사용자 삭제 후 파일 찌꺼기 남음

    이건 생각보다 흔합니다. 파일 서버나 백업 경로에 예전 UID(User ID, 사용자 식별자) 소유 파일이 남아 있으면 나중에 권한 꼬임으로 이어질 수 있습니다. 삭제 전에 파일 검색, 삭제 후 UID 재사용 주의, 이 두 개는 꼭 기억해두면 좋습니다.

    Linux 사용자 관리 트러블슈팅과 sudo 권한 점검 장면 이미지

    sudo 문법 검사, 그룹 확인, SSH 권한 점검 같은 트러블슈팅 과정을 터미널 시점으로 보여주는 이미지입니다.

    7. 검증과 결과 확인: 설정은 했고, 이제 믿어도 되나?

    설정이 끝났다고 바로 안심하면 안 됩니다. 저는 마지막 검증 단계를 따로 두는 편입니다. 왜냐하면 계정과 권한은 “지금 된다”보다 “다음 로그인에서도 일관되게 된다”가 더 중요하거든요.

    7-1. 기본 검증 명령

    id minsu
    getent passwd minsu
    getent group ops
    sudo -l -U minsu
    su - minsu
    whoami
    sudo whoami

    여기서 기대 결과는 명확합니다. 일반 로그인 시에는 사용자 본인, sudo 실행 시에는 root가 나와야 합니다. 그리고 sudo -l -U 사용자명으로 허용된 명령 범위를 눈으로 확인하는 습관이 좋습니다.

    7-2. 운영 기준 체크리스트

    • 루트 직접 SSH 로그인 비활성화 여부 확인
    • 불필요한 계정 잠금 또는 삭제 완료
    • sudo 정책이 그룹 단위로 분리되어 있는지 확인
    • SSH 키 권한과 소유권 점검
    • 계정 생성/변경/삭제 절차를 문서화했는지 확인

    이렇게 정리하고 나니, 서버를 새로 추가해도 기준이 흔들리지 않았습니다. 예전에는 서버마다 계정 상태가 제각각이었는데, 지금은 최소한 “어디를 보면 되는지”가 정해져 있으니 정신이 훨씬 덜 없더라고요.

    Linux 사용자 관리 검증 결과와 체크리스트를 보여주는 이미지

    계정 상태, 그룹 소속, sudo 허용 범위, SSH 점검 항목을 한눈에 확인하는 검증 결과 이미지입니다.

    8. 정리와 다음 단계: Linux 사용자 관리, 결국 기본기가 다 합니다

    이번 글을 한 줄로 정리하면 이겁니다. Linux 사용자 관리는 명령어 몇 개 외우는 일이 아니라, 운영 기준을 만들고 지키는 습관입니다. 제가 1년 동안 계속 다듬어보니 가장 효과가 컸던 건 세 가지였습니다. 일반 사용자 계정으로 작업하기, sudo 권한을 그룹과 정책 파일로 분리하기, 그리고 계정 생애주기(lifecycle, 생성부터 삭제까지)를 끝까지 챙기기. 사실 화려한 기술은 아니지만, 이런 기본기가 서버 안정성을 꽤 오래 받쳐줍니다.

    다음 단계로는 PAM(Pluggable Authentication Modules, 인증 모듈) 정책, SSH 하드닝(hardening, 보안 강화), 그리고 중앙 인증까지 확장해보면 좋습니다. 이전 글에서 다뤘던 SSH 키 운영 방법이 있다면 같이 묶어보셔도 좋고, 다음 글에서는 sudo 로그와 감사(audit, 추적 기록) 중심으로 더 깊게 다뤄볼 예정입니다.

    자주 묻는 질문

    1. 루트 계정을 완전히 안 써도 되나요?
      완전히 안 쓴다기보다, 평소 작업은 일반 계정 + sudo로 돌리고 루트 직접 로그인 빈도를 최소화하는 쪽이 안전했습니다.
    2. sudo 권한은 사용자별로 주는 게 좋나요?
      짧게는 가능하지만, 운영이 길어질수록 그룹 기반 관리가 훨씬 덜 헷갈렸습니다.
    3. 계정 삭제 전에 꼭 확인할 건 뭔가요?
      파일 소유권, 예약 작업, SSH 키, 서비스 참조 여부입니다. 삭제보다 잠금부터 거는 방식이 실무에서 덜 위험했습니다.

    사용자, 그룹, sudo 권한, SSH 보안, 계정 정리 원칙을 한 장으로 요약한 마무리 인포그래픽입니다.

    결국 Linux 운영에서 사고를 줄이는 가장 현실적인 방법은, 계정과 권한부터 차분히 정리하는 겁니다. 화려하진 않지만 효과는 확실합니다. 저도 처음엔 이게 뭔가 싶었는데, 계속 손에 익히고 나니 서버 운영의 체력이 여기서 나온다는 걸 알겠더라고요.