Ubuntu 서버 관리: Cockpit vs Webmin 비교 및 선택 가이드

Cockpit과 Webmin: 간단한 답변

Cockpit과 Webmin은 모두 브라우저를 통해 Linux 서버를 관리하기 위한 웹 패널이며, 각기 다른 목적을 가집니다. Cockpit은 배포판의 자체 저장소에서 제공되며 systemd, journald, polkit, udisks를 통해 시스템을 읽어 들입니다. 따라서 SSH로 관리하던 서버를 그대로 보여주는 역할을 합니다. Webmin은 더 오래되었고 범위가 훨씬 넓습니다. Webmin은 Apache, BIND, Postfix, MariaDB 등 Cockpit이 다루지 않는 수십 가지 서비스의 설정 파일을 직접 수정하며, 이를 위해 root 권한으로 자체 웹 서버를 실행합니다.

단일 서버의 실시간 상태 확인, 로그 조회, 긴급 터미널 접속이 필요하다면 Cockpit을 설치하십시오. 직접 설정하기 번거로운 서비스를 폼(form) 기반 편집기로 관리해야 한다면 Webmin을 설치하십시오. 두 도구 모두 비밀번호 로그인을 사용하는 상태로 공용 포트에 노출해서는 안 됩니다. 이미 2~3대 이상의 서버를 운영 중이라면, 솔직한 답변은 둘 다 사용하지 않는 것입니다. SSH와 Ansible을 조합하는 방식이 어떤 패널보다 확장성이 뛰어납니다.

각 패널에서 실제로 변경할 수 있는 항목

Cockpit의 기본 설치 용량은 작으며, 대부분의 영역은 별도 패키지로 구성되어 있어 제외할 수 있습니다.

• systemd 서비스 및 타이머: 시작, 중지, 활성화 및 unit 파일 읽기
• 저널: unit 및 우선순위별 필터링이 가능하며 journalctl을 통해 날짜를 선택할 수 있음
• 로컬 계정, 그룹 멤버십 및 승인된 SSH 키
• cockpit-storaged을 이용한 스토리지 관리: 파티션, LVM 볼륨 그룹, 파일 시스템 및 마운트 지점
• cockpit-podman를 이용한 컨테이너 관리: Podman만 관리 가능
• cockpit-packagekit을 통한 패키지 업데이트
• cockpit-pcp를 통한 CPU, 메모리, 디스크 및 네트워크 그래프
• 브라우저 탭 내의 root 터미널

Ubuntu VPS에서 두 영역은 작동하지 않는 것처럼 보이지만, 실제로는 그렇지 않습니다. Cockpit의 네트워크 페이지는 NetworkManager의 프론트엔드이며, Ubuntu 서버 이미지는 systemd-networkd와 함께 netplan을 사용하므로 해당 페이지가 없거나 비어 있습니다. 원격 서버에서 이 기능을 복구하려고 NetworkManager를 설치하지 마십시오. 인터페이스 제어권을 가로채기 때문에 설정 실수 시 SSH 세션이 끊길 수 있습니다. Cockpit의 방화벽 제어는 firewalld의 프론트엔드이며, Ubuntu는 ufw를 사용하므로 방화벽 제어 기능을 사용할 수 없습니다. 터미널에서 계속 sudo ufw status를 사용하십시오.

Webmin은 단일 프로그램이 아니라 서비스별 모듈의 집합이므로 훨씬 더 넓은 범위를 다룹니다.

• Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL 및 Samba 설정을 폼을 통해 구성
• 사용자, 그룹 및 디스크 할당량
• cron 작업 및 시스템 시계
• 패키지 업데이트 및 업로드/다운로드가 가능한 파일 관리자
• iptables용 및 firewalld용을 포함한 방화벽 프론트엔드
• 설정 파일 백업 및 변경 사항을 다른 Webmin 서버로 전송하는 클러스터 모듈

Webmin은 /etc 아래의 실제 파일을 편집합니다. 폼 뒤에 숨겨진 데이터베이스는 없으므로, /etc이 버전 관리 시스템에 있다면 폼을 저장한 후 sudo git -C /etc diff을 실행하여 모듈이 작성한 내용을 정확히 확인할 수 있습니다. 이것이 Webmin의 각 페이지가 실제로 수행하는 작업을 배우는 가장 빠른 방법입니다. Webmin 설치 및 첫 로그인 가이드에서 모듈 트리를 자세히 다룹니다. Virtualmin과 Usermin은 동일한 엔진을 기반으로 구축된 별도의 제품으로, 각각 공유 호스팅 및 최종 사용자용으로 설계되었으며 여기서 언급한 노출 관련 사항을 모두 동일하게 상속합니다.

각 인증 방식의 작동 원리

Cockpit은 자체 사용자 데이터베이스를 보유하지 않습니다. 로그인 페이지는 /etc/pam.d/cockpit에서 PAM(pluggable authentication modules) 스택을 실행하므로, 계정은 Unix 계정을 그대로 사용하며 비밀번호 또한 Unix 비밀번호를 따릅니다. /etc/cockpit/disallowed-users에 root가 명시되어 있어 기본적으로 root 로그인은 거부됩니다. 권한이 필요한 작업은 polkit을 거치며, 인터페이스는 변경 사항을 적용하기 전에 비밀번호를 다시 요구합니다. 이 때문에 권한을 상승시키기 전까지 페이지 헤더에 "제한된 접근(Limited access)"이라는 문구가 표시됩니다.

이러한 설계로 인해 보안이 강화된 서버에서는 한 가지 문제가 발생할 수 있습니다. 만약 비밀번호 인증을 비활성화한 키 기반 SSH 로그인 설정을 따랐다면, 해당 계정은 사용할 수 있는 비밀번호가 아예 없을 수 있습니다. 이 경우 ssh은 정상 작동하더라도 Cockpit 로그인은 거부됩니다. 서버에서 다음 명령으로 확인하십시오.

sudo passwd -S deploy

deploy L로 시작하는 출력은 비밀번호가 잠겨 있음을 의미하며, PAM이 수락할 정보가 없으므로 어떤 비밀번호를 입력해도 작동하지 않습니다. P은 사용할 수 있는 비밀번호가 설정되어 있음을 의미합니다. Cockpit의 로그인 페이지 자체는 SSH 키를 허용하지 않습니다. SSH 키는 Cockpit이 로그인한 서버에서 다른 호스트로 연결할 때만 사용됩니다.

Webmin은 /etc/passwd와 분리된 자체 사용자를 /etc/webmin/miniserv.users에 보관하며, Unix 계정을 사용하여 인증하도록 설정할 수도 있습니다. 모든 모듈에 대한 권한을 부여받은 Webmin 사용자는 로그인 셸 설정과 관계없이 해당 머신에서 root 권한을 갖습니다. Webmin은 자체적인 TOTP(time-based one-time password) 지원 기능과 반복적인 로그인 실패 시 호스트를 차단하는 기능을 포함하고 있으며, 두 기능 모두 Webmin Configuration 내에서 활성화할 수 있습니다. Cockpit의 경우 libpam-google-authenticator 등을 사용하여 PAM에 추가적인 인증 단계를 구성해야만 2단계 인증을 사용할 수 있습니다.

각각의 업데이트 방식

Cockpit은 배포판에서 패키지로 제공합니다. Ubuntu 24.04에서는 아카이브를 통해 제공되며, 업스트림 프로젝트에서는 더 최신 빌드를 위해 backports 저장소 사용을 권장합니다.

. /etc/os-release
sudo apt update
sudo apt install -t ${VERSION_CODENAME}-backports cockpit
sudo systemctl status cockpit.socket
apt policy cockpit

apt policy은 설치된 버전과 해당 버전이 제공된 저장소를 출력합니다. backports에 더 최신 빌드가 없다면 apt는 아카이브 버전으로 대체하며, 이는 정상적인 동작입니다. cockpit.socket의 출력값은 active (listening)여야 합니다. 보안 패치는 커널과 동일한 unattended-upgrades 실행 과정을 통해 이미 신뢰하는 게시자로부터 전달됩니다.

Webmin은 Ubuntu 아카이브에 포함되어 있지 않습니다. 공식 설치 방식은 먼저 Webmin 자체 저장소와 서명 키를 추가합니다.

curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh
sudo apt-get install webmin --install-recommends

해당 스크립트는 root 권한으로 실행되므로 실행하기 전에 내용을 확인하십시오. 이후 서버에서 실행하는 모든 apt upgrade은 Webmin 저장소에서도 패키지를 가져오게 되며, 이는 서버에 root 수준의 신뢰 권한을 가진 두 번째 게시자를 추가하는 셈입니다. 이것이 Webmin 사용의 실질적인 비용이며, 명확한 사례가 있습니다. CVE-2019-15107은 여러 1.9x 패키지에 포함된 백도어로, 인증되지 않은 명령 실행을 허용했습니다. 이 취약점은 소스 저장소가 아닌 프로젝트의 빌드 호스트가 해킹당하면서 사용자에게 전달되었습니다. 배포판 패키징이 이러한 위험을 완전히 제거하는 것은 아닙니다. 하지만 사용자가 직접 관리하지 않아도 되는 빌드 및 검토 단계를 추가해 줍니다.

공용 포트에 두 서비스를 모두 두어서는 안 되는 이유

Cockpit은 TCP 9090 포트에서, Webmin은 TCP 10000 포트에서 TLS(전송 계층 보안)를 통해 동작하며, 기본적으로 자체 서명 인증서를 사용하므로 브라우저에서 경고가 표시됩니다. 자체 서명 인증서 생성 및 신뢰하기에서 해당 경고가 의미하는 바와 그렇지 않은 바를 설명합니다. 두 포트 모두 지속적으로 스캔 대상이 되며, 두 패널 모두 root 권한으로 이어지므로 비밀번호가 유출되거나 재사용될 경우 서버 전체가 침해될 수 있습니다.

안전한 방식은 패널을 localhost에 바인딩하고 SSH 터널을 통해 접속하는 것입니다. Cockpit의 경우 소켓 유닛을 재정의(override)하십시오.

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

빈 ListenStream= 줄이 반드시 필요합니다. systemd는 설정 목록을 추가하는 방식으로 동작하므로, 이 줄이 없으면 기존 0.0.0.0:9090 설정이 유지된 채 새로운 주소가 추가되어 패널이 여전히 외부에 공개됩니다. 재정의를 적용하고 리스닝 상태를 확인하십시오.

sudo systemctl daemon-reload
sudo systemctl restart cockpit.socket
sudo ss -lntp | grep 9090

출력 결과에 127.0.0.1:9090가 표시되어야 합니다. *:9090나 0.0.0.0:9090으로 표시된다면 재정의가 적용되지 않은 것입니다. 이제 로컬 머신에서 터널을 열고 https://localhost:9090로 접속하십시오.

ssh -N -L 9090:127.0.0.1:9090 deploy@203.0.113.10

로컬 포트와 원격 포트를 동일하게 유지하십시오. Cockpit은 브라우저의 Origin 헤더와 자신이 서비스 중이라고 판단하는 주소를 비교합니다. 따라서 로컬 포트 9999로 터널을 연결하면 로그인 페이지는 로드되지만 로그인 시도 시 실패하며, journalctl -u cockpit에 거부된 출처가 기록됩니다. 다른 로컬 포트가 필요하다면 /etc/cockpit/cockpit.conf에 지정하십시오.

[WebService]
Origins = https://localhost:9999 https://127.0.0.1:9999

sudo systemctl restart cockpit.socket 명령으로 재시작하여 설정을 반영하십시오. Webmin의 경우 동일한 설정이 /etc/webmin/miniserv.conf에 위치합니다.

bind=127.0.0.1

sudo systemctl restart webmin
sudo ss -lntp | grep 10000
ssh -N -L 10000:127.0.0.1:10000 deploy@203.0.113.10

Webmin은 폼 전송 시 Referer 헤더를 확인하며, 다른 호스트에서 온 것으로 판단되는 요청은 거부합니다. 이것이 리버스 프록시 설정 시 첫 시도가 실패하는 이유입니다. 동일 파일의 referers= 줄에 프록시의 호스트 이름을 허용하고, webprefix=에 Webmin이 특정 경로 하위에서 동작함을 명시해야 합니다.

인증된 리버스 프록시를 사용하는 것도 다른 방법입니다. nginx를 앞단에 두고 Authentik 싱글 사인온 계층을 통해 로그인하는 방식입니다. 이 방식도 동작하며 차선책이 될 수 있습니다. 하지만 패널은 여전히 프록시 뒤에서 root 권한으로 실행되며, 관리해야 할 출입구가 하나에서 둘로 늘어납니다. SSH 터널을 사용하면 인터넷에 노출되는 리스닝 서비스가 전혀 없으며, 이미 보호 중인 SSH 키를 재사용할 수 있습니다.

운영 중인 서버에 어떤 패널을 설치해야 하는가

다른 사용자가 의존하는 서버라면 두 가지 이유로 Cockpit을 권장합니다. 첫째, 소켓 활성화(socket activated) 방식으로 작동하므로 세션이 열려 있을 때만 cockpit-ws이 실행되며, 포트에서 상시 대기하는 루트 데몬이 없습니다. 둘째, 시스템 설정을 소유하지 않습니다. 패키지를 삭제해도 Cockpit은 자체 설정을 저장하지 않으므로 모든 서비스가 이전과 동일하게 계속 실행됩니다. 반면 Webmin의 miniserv.pl은 사용자의 로그인 여부와 관계없이 상주합니다. systemctl status webmin 명령어를 실행하면 현재 실행 중인 프로세스의 상주 메모리 사용량을 확인할 수 있으므로, 직접 비용을 확인해 보십시오.

Webmin의 DNS나 메일 모듈이 반드시 필요하다면 해당 기능을 위한 별도의 서버를 마련하십시오. 127.0.0.1에 바인딩되어 단일 작업만 수행하는 Webmin 서버는 위험이 격리되어 있습니다. 고객에게 서비스를 제공하는 애플리케이션과 Webmin을 같은 호스트에서 공유하는 것은 위험합니다. 어떤 패널을 설치하든 그전에 기본 작업을 완료하십시오. 새로운 VPS에서의 첫 10분 가이드에서는 두 패널 모두 이미 설정되어 있다고 가정하는 비루트 사용자 계정 생성과 방화벽 설정을 다룹니다.

답이 어느 쪽도 아닐 때

패널은 서버별로 수동 관리하며, 무엇이 왜 변경되었는지 기록을 남기지 않습니다. 서버가 한 대라면 괜찮습니다. 다섯 대가 되면 같은 작업을 반복하게 되고, 스무 대가 되면 어떤 서버에서 변경 사항이 누락되었는지 추측해야 합니다. Cockpit은 SSH를 통해 한 세션에 다른 호스트를 추가할 수 있지만, 최신 버전은 기본적으로 이 기능을 비활성화하고 AllowMultiHost=yes을 /etc/cockpit/cockpit.conf에 요구합니다. 또한 여전히 같은 변경 사항을 다섯 번 클릭해야 하는 문제는 남습니다.

대안은 설정을 git 저장소에 보관하고 일반 SSH를 사용하는 것입니다. 한 곳에서 여러 Linux 서버 관리하기는 해당 설정의 형태를 다루며, 첫 번째 Ansible 플레이북은 diff로 검토 가능한 단일 파일에서 모든 호스트에 동일한 방화벽 규칙을 적용하는 방법을 설명합니다. 컨테이너 작업도 마찬가지입니다. Docker Compose 기초 가이드에서처럼 git의 파일을 사용하여 SSH를 통해 docker compose up -d를 실행하는 것이 패널을 클릭하는 것보다 훨씬 효율적이며, 애초에 Cockpit은 Docker를 관리하지 않습니다.

메트릭 그래프를 읽거나 40개의 유닛 중 어떤 것이 실패했는지 확인하는 등 터미널로 하기 어려운 작업에는 패널을 사용하십시오. 두 번 이상 반복할 작업은 무엇이든 코드로 처리하십시오.

실패 유형 및 확인되는 메시지

SSH에서는 허용되는 비밀번호를 Cockpit에서 거부합니다. 해당 계정은 키 전용 인증을 사용 중입니다. sudo passwd -S alice은 두 번째 필드에 L를 출력하므로, PAM이 확인할 비밀번호가 존재하지 않습니다. sudo passwd alice로 비밀번호를 설정하거나, 해당 계정은 SSH용으로 유지하고 다른 사용자로 Cockpit에 로그인하십시오.

올바른 비밀번호를 입력해도 Cockpit이 root 로그인을 거부합니다. /etc/cockpit/disallowed-users은 root을 나열합니다. sudo 권한이 있는 일반 사용자로 로그인하십시오. 이는 polkit이 권한을 상승시킨 사용자를 기록하도록 설계된 의도된 경로입니다.

Cockpit에 Networking 또는 Firewall 페이지가 표시되지 않습니다. 해당 페이지들은 NetworkManager와 firewalld를 필요로 합니다. Ubuntu VPS는 systemd-networkd와 ufw를 사용하는 netplan으로 구동되므로 해당 페이지가 나타나지 않습니다. 시스템에 문제가 있는 것은 아니며, SSH를 통해 ufw을 계속 사용하는 것이 해결책입니다.

터널을 통해 Cockpit 로그인 페이지는 로드되지만 로그인이 실패합니다. 로컬 포트와 원격 포트가 일치하지 않아 Origin 검사가 실패하고 journalctl -u cockpit에 해당 내용이 표시됩니다. 포트를 일치시키거나 /etc/cockpit/cockpit.conf 파일에서 Origins을 설정하십시오.

프록시 뒤에 배치한 후 Webmin 폼 전송이 실패합니다. Referer 검사가 이를 거부하기 때문입니다. /etc/webmin/miniserv.conf 파일의 referers=에 프록시 호스트 이름을 추가하고, 패널이 특정 경로 하위에서 서비스되는 경우 webprefix=을 설정하십시오.

패널이 외부로 노출되었는지 확실하지 않습니다. sudo ss -lntp | grep -E '9090|10000' 명령을 서버에서 직접 실행하여 확인할 수 있으며, Webmin은 모든 로그인 시도를 /var/webmin/miniserv.log에 기록합니다. 리스닝 설정 변경 후에는 이 로그를 한 번 확인하는 것이 좋습니다.

FAQ

단일 Ubuntu VPS에는 Cockpit과 Webmin 중 무엇이 더 나은가요?

대부분의 사용자에게는 Cockpit을 권장합니다. Ubuntu 공식 저장소에서 제공되어 시스템과 함께 패치되며, 브라우저 세션이 열려 있을 때만 실행되기 때문입니다. Cockpit이 지원하지 않는 BIND나 Postfix 같은 서비스를 폼 기반 편집기로 관리해야 할 때만 Webmin을 선택하십시오. 단, Webmin의 웹 서버는 항상 root 권한으로 실행되며 업데이트는 Webmin 자체 저장소를 통해 이루어진다는 점을 감수해야 합니다.

같은 서버에서 Cockpit과 Webmin을 동시에 실행할 수 있나요?

네, 가능합니다. 두 서비스는 각각 9090과 10000 포트를 사용하므로 충돌하지 않으며, 시스템을 직접 수정하는 방식이라 서로 간섭하지 않습니다. 하지만 권장하지는 않습니다. 두 패널 모두 동일한 머신에서 root 권한을 가진 별도의 로그인 경로가 되므로, 클릭 몇 번을 편하게 하려다 공격 노출 면적만 두 배로 늘리는 꼴이 됩니다. 두 패널을 모두 설치한다면 둘 다 127.0.0.1에 바인딩하고 SSH 터널을 통해 접속하십시오.

9090이나 10000 포트를 인터넷에 개방해도 안전한가요?

비밀번호 로그인을 사용하는 경우 안전하지 않습니다. 두 패널 모두 root 권한으로 이어지며, 포트를 개방하면 몇 시간 내에 일상적인 스캔에 의해 발견됩니다. 패널을 127.0.0.1에 바인딩한 뒤 ssh -N -L 9090:127.0.0.1:9090 user@host을 실행하고 https://localhost:9090로 접속하십시오. sudo ss -lntp | grep 9090으로 확인했을 때 0.0.0.0:9090가 아닌 127.0.0.1:9090가 출력되어야 합니다. 인증이 적용된 리버스 프록시를 사용하는 것은 허용 가능한 두 번째 선택지입니다.

SSH 키 로그인은 되는데 왜 Cockpit 로그인은 실패하나요?

Cockpit은 PAM을 통해 Unix 비밀번호로 인증하며, 로그인 페이지에서 SSH 키를 허용하지 않습니다. 보안이 강화된 서버에서는 계정에 사용 가능한 비밀번호가 없는 경우가 많습니다. sudo passwd -S youruser을 실행해 보십시오. 두 번째 필드에 L이 표시된다면 비밀번호가 잠겨 있다는 뜻이며, 따라서 PAM이 수락할 정보가 없어 모든 시도가 거부됩니다. sudo passwd youruser을 사용하여 비밀번호를 설정하거나, 패널용으로 별도의 계정을 사용하십시오.

Cockpit으로 Docker 컨테이너를 관리할 수 있나요?

아니요. Cockpit의 컨테이너 페이지는 cockpit-podman에서 제공하며 Podman을 관리합니다. 오래된 Docker 모듈은 수년 전에 삭제되었으며 다시 추가되지 않을 것입니다. 서비스가 Docker 기반으로 실행 중이라면 SSH를 통해 버전 관리 중인 compose 파일로 관리하고, 시스템 로그나 디스크 관리 등 주변 시스템은 Cockpit이 담당하게 하십시오.