sudo with MFA

sudo with MFA를 사용하면 영구적인 sudo 권한 없이 Websh 터미널 세션에서 sudo 명령어를 실행할 수 있습니다. sudo 명령어를 입력하면 실행 전에 MFA 확인이 필요합니다.

요구 사항#

• 대상 서버에 Alpamon 1.3.2 이상 설치 필요
• Policies의 접근 규칙에서 sudo 탭 상단의 Alpacon을 통한 sudo을 켜야 함(서버에 필요한 PAM 모듈이 자동으로 설치됨)

sudo with MFA 활성화#

1. 사이드바에서 Policies > Access rules(접근 규칙)로 이동해 sudo 탭을 여세요(sudo 및 root 접근 참고).
2. Alpacon을 통한 sudo을 켜세요.
3. 그 시점에 연결된 Alpamon 1.3.2+ 실행 서버에 PAM 모듈이 자동으로 설치됨

sudo with MFA 비활성화#

접근 규칙의 sudo 탭에서 Alpacon을 통한 sudo을 끄면 즉시 적용되며, 워크스페이스 전체의 동작이 다음과 같이 바뀝니다.

• Alpacon이 sudo 인가를 중지함. PAM 모듈 설치 여부와 관계없이 모든 서버에서 Alpacon에 도달한 sudo 요청이 거부됨. 거부 코드 WORKSPACE_SUDO_WITH_MFA_DISABLED가 표시됨. “Alpacon denied this sudo command” 참고. Alpacon이 호스트를 관리하기 전부터 자체 sudoers 권한이 있던 시스템 계정은 그 권한을 유지함
• 서버는 변경되지 않음. 패키지를 제거하거나 서버에 명령어를 보내지 않음. alpamon-pam 패키지와 그 설정 및 관리하는 sudoers 규칙은 그대로 유지되지만, 설정이 꺼져 있는 동안에는 효력이 없음
• 이미 승인을 기다리는 요청은 거부되지 않음. 승인 대기열에 남아 있지만 승인해도 sudo 명령어를 실행할 수 없으며, 관련 인가는 정해진 만료 시각에 만료됨
• “Websh 외부에서 sudo 차단” 설정이 꺼짐. 이 설정은 sudo with MFA에 의존하므로 자동으로 꺼짐

Alpacon을 통한 sudo을 다시 켜면 sudo 인가가 즉시 재개됩니다. 그 시점에 연결된 모든 서버에도 alpamon-pam이 설치되므로, 아직 패키지가 없는 서버도 설치됩니다.

작동 방식#

터미널에서 sudo 명령어를 실행하면 다음과 같이 진행됩니다.

1. sudo 명령어 입력(예: sudo systemctl restart nginx)
2. 터미널에 MFA 인증이 필요해요 화면이 표시됨. 클릭하여 인증하기를 클릭하면 인증 창이 열림
3. MFA 인증을 마치면 명령어가 실행됨
4. sudo with MFA 타임아웃이 끝날 때까지 이후 sudo 명령어에는 MFA 인증이 다시 필요하지 않음. 이 시간은 워크스페이스 관리자가 접근 규칙에서 설정함

인증에 실패하거나 MFA 세션이 만료되면, 터미널에서 명령어를 다시 실행해 재인증하라는 안내가 표시됩니다.

인증을 완료할 수 있는 로그인 방식#

sudo MFA 인증은 웹 콘솔에 로그인했거나 alpacon login으로 브라우저 로그인을 마친 CLI 사용자만 완료할 수 있습니다. 개인 API 접근 토큰, 서비스 토큰, AI 에이전트의 MCP 연결처럼 자체 MFA 인증이 없는 자격 증명으로는 사용할 수 없습니다. 그 자격 증명을 쓰는 사람이 다른 곳에서 인증을 마쳤더라도 마찬가지입니다.

CLI에 API 토큰으로 로그인했다면(alpacon login -t), MFA가 필요한 sudo 명령어는 “Sudo MFA cannot be completed with this credential” 메시지와 함께 중지됩니다. -t 없이 alpacon login으로 다시 로그인한 뒤 명령어를 다시 실행하세요. 사람의 개입 없이 sudo가 필요한 작업에는 MFA 우회 sudo 정책이 적용되는 작업 세션(alpacon work-session create --sudo 참조)이나 명령 패턴과 sudo에 설명된 서비스 토큰을 사용하세요.

Auth0가 없는 배포#

sudo with MFA 인증에는 Auth0가 필요합니다. Auth0가 없는 자체 호스팅 배포 환경에서는 MFA 인증이 필요한 sudo 명령어를 실행하면 완료할 수 없는 인증 창을 여는 대신 SUDO_STEP_UP_UNAVAILABLE 코드와 함께 즉시 거부됩니다. 이 환경에서 sudo 권한을 얻으려면 MFA 우회 sudo 정책이 적용되는 작업 세션을 사용하세요(alpacon work-session create --sudo 참조).

승인 대기#

Websh 터미널에서 대화형 sudo 명령어를 실행할 때 다른 사람의 승인이 필요하면 터미널이 승인자의 결정을 기다립니다. 규칙에 따라 승인이 필요하거나(SUDO_APPROVAL_REQUIRED), 명령어가 작업 세션의 목적에서 벗어나거나(SUDO_INTENT_DEVIATION), 실행할 상시 권한이 없을 때(SUDO_NO_AUTHORITY) 대기합니다. 단, 실행 제어가 Advisory인 워크스페이스에서는 상시 권한이 없으면 즉시 거부됩니다.

자체 호스팅 환경에서 승인 대기 기능을 사용하려면 Alpacon 2.44.0 이상, Alpamon 2.8.4 이상, alpamon-pam 1.2 이상이 필요합니다. 이전 버전에서 sudo가 어떻게 동작하는지는 sudo 명령어가 거부될 때를 참고하세요.

터미널에 표시되는 내용#

1. 터미널에 승인을 기다리는 중입니다 (요청 <요청 ID>, <분>분 후 만료) ...가 표시되고, 승인자가 결정하거나 대기가 끝날 때까지 명령어 실행이 멈춤. 최대 5분 동안 기다리며 승인 가능 시간이 더 짧으면 그 시간까지만 기다림
2. 승인자가 요청을 승인한 경우:
   • 콘솔에서 활동 중이라면 명령어가 바로 실행됨
   • 추가 MFA 인증이 필요하다면 콘솔에 인증 화면이 표시됨. 인증을 마치면 명령어가 실행됨
3. 승인자가 요청을 거절하거나 요청자가 철회하면 터미널에 거절 메시지가 표시되고 명령어는 실행되지 않음
4. 대기가 끝날 때까지 결정이 없거나 승인 후 MFA 인증을 마치지 못하면 SUDO_APPROVAL_PENDING과 함께 승인 요청이 계속 유효하다는 안내가 표시됨. 승인된 뒤 같은 명령어를 다시 실행해야 함

대기를 멈추려면 Ctrl+C를 누르세요. 터미널에 You stopped waiting. The request stays open; run the command again once it's approved (SUDO_APPROVAL_PENDING).가 표시됩니다. 승인 요청은 계속 유효하므로 승인된 뒤 명령어를 다시 실행할 수 있습니다.

한 터미널에서 승인을 기다리는 동안 다른 터미널에서 같은 sudo 명령어를 실행하면 두 번째 명령어는 SUDO_APPROVAL_ALREADY_WAITING으로 거부됩니다. 대기 중인 터미널을 사용하거나 그 터미널에서 먼저 Ctrl+C를 누르세요. 명령어가 같은지 판단할 때는 실행 대상 계정과 -u로 지정한 계정도 확인합니다. 따라서 sudo -u alice cmd와 sudo -u bob cmd는 각각 기다릴 수 있습니다.

터미널이 기다리지 않는 경우#

다음 경우에는 터미널이 승인 결정을 기다리지 않습니다.

• 작업 세션 밖의 Websh 세션: 이전과 같이 sudo가 거부됨
• 대화형이 아닌 sudo: sudo -n, sudo -S, sudo -b 등
• AI 에이전트와 서비스 토큰
• 상시 sudo 권한이 없는 Advisory 워크스페이스: SUDO_NO_AUTHORITY로 즉시 거부되고 승인 요청도 생성되지 않음. 워크스페이스 소유자에게 서버 접근 정책에서 상시 sudo 권한 부여 요청 필요
• 즉시 거부되는 명령어: 다른 사람의 개인 계정으로 전환하거나 우회 및 범위 제한에 걸린 명령어 등
• 본인 외에 승인자가 없는 요청: APPROVAL_NO_OTHER_APPROVER로 즉시 거부됨. 두 번째 승인자나 자동 승인 규칙 추가 필요

승인자를 위한 안내#

승인자에게는 달라지는 점이 없습니다. 요청은 이전처럼 요청 관리 페이지에 표시됩니다. 요청 검토에 따라 검토하세요.

sudo 명령어가 거부될 때#

Alpacon이 Websh 터미널에서 sudo 명령어를 거부하면 명령어는 실행되지 않고, 터미널에 괄호로 묶인 코드가 포함된 한 줄이 출력됩니다.

Alpacon denied this sudo command (SUDO_APPROVAL_REQUIRED).

아래 세 코드는 명령어 자체에 관한 것이며, 여기서 안내하는 대응 방법은 Websh에 적용됩니다. 토큰이나 alpacon exec로 실행한 명령어는 다르게 처리되므로 명령 패턴과 sudo를 참고하세요. 다른 코드에 대해서는 “Alpacon denied this sudo command”을 참고하세요.

SUDO_APPROVAL_REQUIRED#

이 명령어를 실행하려면 다른 사람의 승인이 필요하며, Alpacon은 이미 승인 요청을 보냈습니다. 워크스페이스에서 요청을 승인할 수 있는 다른 사람에게 요청 관리 페이지에 요청이 표시됩니다. 승인을 받으면 같은 명령어를 다시 실행하세요. 서버와 에이전트가 승인 대기에 적힌 버전 이상이면 이 거부 메시지 대신 터미널이 승인을 기다립니다. 아무도 결정하지 않은 요청은 몇 분 뒤 만료됩니다.

SUDO_INTENT_DEVIATION#

현재 Websh 세션은 작업 세션에 속해 있으며, 명령어가 그 작업 세션에 적힌 목적과 맞지 않습니다. SUDO_APPROVAL_REQUIRED와 마찬가지로 Alpacon이 승인 요청을 보냈으므로, 승인을 기다렸다가 명령어를 다시 실행할 수 있습니다. 서버와 에이전트가 승인 대기에 적힌 버전 이상이면 터미널에서 결정을 기다릴 수도 있습니다. 작업 내용이 원래 목적에서 달라졌다면 새 목적을 적어 작업 세션을 새로 요청하고 그 세션에서 명령어를 실행하세요.

SUDO_RISK_DENIED#

워크스페이스의 접근 규칙이 차단했거나 명령어의 위험도가 너무 높다고 판단되어, 이 명령어는 sudo로 실행할 수 없습니다. 승인 요청은 생성되지 않으며, 같은 명령어를 다시 실행해도 결과는 같습니다. 슈퍼유저에게 Policies의 접근 규칙 페이지에서 규칙을 검토해 달라고 요청하세요.

sudo 정책과 부여#

sudo 명령어의 인가 방식은 Policies의 접근 규칙에 있는 sudo 탭의 규칙에 따라 달라집니다.

• Sudo 정책: 관리자가 특정 사용자나 서버에 대해 지정한 명령어를 미리 인가할 수 있음. 작업 세션에 연결된 정책은 MFA 우회를 허용할 수 있어, exec를 실행하는 AI 에이전트처럼 대화형 입력을 할 수 없는 호출자가 지정된 명령어를 대화형 MFA 요청 없이 실행할 수 있음
• 승인: 관리자의 승인으로 sudo 요청을 인가할 수 있음

직접 부여한 권한, 정책, 승인 중 어떤 방식으로 인가했든 기록이 남습니다. Sudo 기록에서 확인하세요.

sudo-rs 호환성#

Ubuntu 25.10 이상 버전(26.04 포함)에서는 sudo-rs가 기본 sudo로 제공됩니다. 이 호스트에서도 sudo with MFA를 사용할 수 있지만 alpamon-pam 패키지 1.1.2 이상이 필요합니다. Alpacon은 sudo-rs를 탐지하고 PAM으로 sudo 명령어를 인가합니다.

기존 sudo(1.9+)에서는 Alpacon이 별도의 sudo 승인 플러그인도 /etc/sudo.conf에 등록합니다. sudo-rs에는 플러그인 인터페이스가 없어 sudo-rs 호스트에서는 이 플러그인을 사용하지 않으며 /etc/sudo.conf에도 나타나지 않습니다. 이는 예상된 동작이며 설정 오류가 아닙니다.

관련 문서#

• 명령어 실행하기
• 계정 선택
• 워크스페이스 설정
• 명령 패턴과 sudo