대상 OS: Rocky Linux 9

사용자/그룹 정리는 단순히 계정을 지우는 작업이 아니라, 접속 경로(SSH/콘솔), 서비스 실행 사용자, 파일 소유권, sudo 권한까지 얽혀 있는 운영 작업입니다. 현장에서 가장 흔한 사고는 “정리하다가 접속이 끊겨서 복구가 어려워지는” 형태입니다. 그래서 순서가 전부입니다.

정리 작업 전: ‘끊기지 않는’ 안전장치부터 만들기

  1. 1) 지금 누가/어디서 로그인 중인지 확인(영향 범위 파악)

    # 현재 로그인 세션
who
w

# 최근 로그인 기록
last -n 20

# sshd 인증 로그(최근)
sudo journalctl -u sshd --since "24 hours ago" --no-pager | tail -n 200

    이 단계에서 “실제로 쓰는 계정인지, 배치/자동화가 쓰는 계정인지” 힌트를 얻습니다.


  2. 2) 대체 관리자 경로 확보(백도어가 아니라 ‘정상 대체 경로’)

    정리 대상이 관리자 계정/그룹과 얽혀 있다면, 작업 전에 반드시 다른 관리자 계정과 다른 접속 경로(예: 콘솔/세컨 SSH 세션)를 확보하세요.

    # 예: 별도의 관리자 계정 생성(필요 시)
sudo useradd -m -s /bin/bash admin2
sudo passwd admin2

# wheel(sudo) 권한 부여
sudo usermod -aG wheel admin2

# sudo 동작 확인
sudo -l -U admin2


  3. 3) “정리 대상 사용자”가 어떤 리소스를 소유/사용 중인지 찾기

    이 부분을 건너뛰면, 계정 삭제 후 서비스/배치가 깨지거나 데이터 접근 권한이 꼬입니다.

    TARGET_USER="olduser"

# 프로세스 점유(동작 중이면 먼저 종료/이관 계획)
ps -u "$TARGET_USER" -o pid,ppid,cmd --forest

# crontab/at 작업 확인
sudo crontab -l -u "$TARGET_USER" || true
sudo ls -al /var/spool/cron/ || true

# systemd 서비스가 해당 사용자로 실행되는지 확인(서비스 유닛 점검)
sudo systemctl list-unit-files --type=service --no-pager | head -n 50
# 필요 시: 특정 서비스 유닛 내 User= 검색
sudo rg -n "^User=|^Group=" /etc/systemd/system /usr/lib/systemd/system 2>/dev/null || true

# 파일 소유권(범위를 좁혀서 시작: /home, /var/www, /srv 등)
sudo find /home /srv /var/www -xdev -user "$TARGET_USER" -print | head -n 200


  4. 4) 삭제 대신 ‘잠금(Lock)’으로 1차 차단(운영 안전)

    바로 삭제하면 복구가 어렵습니다. 먼저 로그인/인증을 막고(잠금), 운영 영향이 없는지 확인한 뒤 삭제하는 게 사고를 줄입니다.

    TARGET_USER="olduser"

# 비밀번호 로그인 잠금(계정 잠금)
sudo passwd -l "$TARGET_USER"

# 쉘 접근 차단(선택): /sbin/nologin 으로 변경
sudo usermod -s /sbin/nologin "$TARGET_USER"

# SSH 키 기반 접근도 막아야 한다면(authorized_keys 확인/회수)
sudo ls -al "/home/$TARGET_USER/.ssh" || true


  5. 5) sudo 권한/그룹 권한 정리(특권 제거가 핵심)

    TARGET_USER="olduser"

# 그룹 확인
id "$TARGET_USER"
getent group wheel

# wheel 등 특권 그룹에서 제거
sudo gpasswd -d "$TARGET_USER" wheel || true

# sudoers/드롭인에서 해당 사용자 언급 검색
sudo visudo -c
sudo rg -n "\b${TARGET_USER}\b" /etc/sudoers /etc/sudoers.d 2>/dev/null || true


  6. 6) 최종 삭제(필요 시 홈 디렉토리/메일 스풀 처리 포함)

    삭제 전, 반드시 파일/소유권 이관이 끝났는지 확인하세요.

    TARGET_USER="olduser"

# 삭제(홈 포함)
sudo userdel -r "$TARGET_USER"

# 삭제 후 잔여 소유 파일 확인(UID가 남는 경우)
# (삭제 전 UID 기록해두면 좋음)
# id -u olduser
# sudo find / -xdev -uid 12345 -print | head -n 200


사례(현장에서 자주 겪는 상황)

  • 정리하던 계정이 사실상 배치(cron) 계정: 계정 삭제 후 새벽 배치가 전부 실패하고 아침에 장애로 터짐.
  • wheel에서 제거했더니 운영자가 sudo를 못함: 실제 운영자가 그 계정을 공용으로 쓰고 있었거나, 대체 관리자 계정이 없었음.
  • 서비스 유닛의 User=가 정리 대상이었음: 재시작/재부팅 후 서비스 기동 실패.
  • 홈 디렉토리를 지우며 중요 키/설정도 같이 삭제: 퇴사자 계정 정리 중, 운영에 쓰던 SSH 키/배포 키까지 같이 제거.

트러블슈팅(증상→원인→해결)

  • 증상: 계정 삭제 후 특정 서비스가 재시작하면 실패

    원인: systemd 유닛에서 User=olduser로 실행 중이었음

    해결: 유닛 파일에서 실행 사용자 변경 → 필요한 파일 소유권/권한 이관 → systemctl daemon-reload 후 재기동

  • 증상: 운영자들이 sudo를 못하게 됨

    원인: 공용 계정을 제거했거나, wheel 권한 구조를 이해하지 못하고 정리

    해결: 콘솔/대체 관리자 계정으로 복구 → 최소 2개 관리자 계정 유지 → 공용 계정 금지 정책 수립

  • 증상: 야간 배치가 전부 실패(권한/파일 없음)

    원인: crontab/스크립트가 삭제된 홈 디렉토리를 참조

    해결: 배치 계정은 삭제 대신 잠금+소유권 이관 → 배치 스크립트는 /opt 또는 /srv 등 표준 경로로 이전

요약하면, 사용자/그룹 정리는 “삭제”가 아니라 특권 제거 → 영향도 확인 → 안전한 차단 → 최종 삭제의 흐름으로 진행해야 사고가 줄어듭니다.

- 이 글은 ai가 random적으로 만들어 올리는 글입니다. -