Cockpit czy Webmin: co wybrać do zarządzania serwerem?

Cockpit a Webmin: krótka odpowiedź

Cockpit i Webmin to panele webowe służące do zarządzania serwerem Linux z poziomu przeglądarki, jednak odpowiadają na różne potrzeby. Cockpit jest dostarczany w oficjalnych repozytoriach dystrybucji i odczytuje stan maszyny za pośrednictwem systemd, journald, polkit oraz udisks, dzięki czemu prezentuje serwer, którym nadal zarządza się przez SSH. Webmin jest starszym i znacznie bardziej rozbudowanym narzędziem: modyfikuje pliki konfiguracyjne Apache, BIND, Postfix, MariaDB oraz dziesiątek innych usług, których Cockpit nie obsługuje, a do działania uruchamia własny serwer WWW z uprawnieniami root.

Zainstaluj Cockpit, jeśli potrzebujesz podglądu na żywo pojedynczej maszyny, przeglądarki logów oraz terminala awaryjnego. Zainstaluj Webmin, gdy potrzebujesz edytora opartego na formularzach dla usługi, której nie chcesz konfigurować ręcznie. Nie wystawiaj żadnego z tych narzędzi na publiczny port z logowaniem hasłem. Jeśli zarządzasz więcej niż dwoma lub trzema serwerami, uczciwa odpowiedź brzmi: nie używaj żadnego z nich, ponieważ podejście oparte na SSH oraz Ansible skaluje się lepiej niż jakikolwiek panel.

Co może zmienić każdy z paneli

Podstawowa instalacja Cockpit jest niewielka, a większość obszarów to osobne pakiety, które można pominąć:

• usługi i timery systemd: uruchamianie, zatrzymywanie, włączanie oraz odczyt pliku jednostki
• dziennik (journal), filtrowany według jednostki i priorytetu, który jest journalctl z wyborem daty
• konta lokalne, przynależność do grup oraz autoryzowane klucze SSH
• pamięć masowa z cockpit-storaged: partycje, grupy wolumenów LVM, systemy plików i punkty montowania
• kontenery z cockpit-podman, co obsługuje wyłącznie Podman
• aktualizacje pakietów z cockpit-packagekit
• wykresy CPU, pamięci, dysku i sieci z cockpit-pcp
• terminal root w karcie przeglądarki

Dwa obszary wyglądają na uszkodzone na VPS z Ubuntu, choć tak nie jest. Strona sieciowa Cockpit to interfejs dla NetworkManager, a obrazy serwerowe Ubuntu używają netplan z systemd-networkd, więc strona ta jest nieobecna lub pusta. Nie należy instalować NetworkManager na zdalnej maszynie, aby ją przywrócić, ponieważ przejmuje on kontrolę nad interfejsem, a błąd w konfiguracji spowoduje utratę sesji SSH. Kontrola zapory sieciowej w Cockpit to interfejs dla firewalld, a Ubuntu używa ufw, więc użytkownik nie otrzymuje żadnej kontroli nad zaporą. Należy nadal używać sudo ufw status w terminalu.

Webmin obejmuje znacznie szerszy zakres, ponieważ jest zbiorem modułów dla poszczególnych usług, a nie jednym programem:

• konfiguracja Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL i Samba za pomocą formularzy
• użytkownicy, grupy i limity dyskowe (quotas)
• zadania cron i zegar systemowy
• aktualizacje pakietów oraz menedżer plików z funkcją przesyłania i pobierania
• interfejsy zapory sieciowej, w tym jeden dla iptables i jeden dla firewalld
• kopie zapasowe plików konfiguracyjnych oraz moduły klastrowe, które przesyłają zmiany do innych serwerów Webmin

Webmin edytuje rzeczywiste pliki w /etc. Za formularzami nie kryje się żadna ukryta baza danych, więc jeśli /etc jest objęte kontrolą wersji, sudo git -C /etc diff po zapisaniu formularza pokazuje dokładnie to, co zapisał moduł. Jest to najszybszy sposób, aby dowiedzieć się, co faktycznie robi dana strona Webmin. Instrukcja instalacji Webmin i pierwszego logowania szczegółowo omawia drzewo modułów. Virtualmin i Usermin to osobne produkty zbudowane na tym samym silniku, przeznaczone odpowiednio dla hostingu współdzielonego i użytkowników końcowych; dziedziczą one wszystko, co powiedziano tutaj na temat ekspozycji.

Sposób uwierzytelniania poszczególnych rozwiązań

Cockpit nie posiada własnej bazy użytkowników. Strona logowania korzysta ze stosu PAM (pluggable authentication modules) w /etc/pam.d/cockpit, dlatego używane są konta i hasła systemowe Unix. Logowanie użytkownika root jest domyślnie blokowane, ponieważ znajduje się on na liście w /etc/cockpit/disallowed-users. Działania wymagające uprawnień są obsługiwane przez polkit, a interfejs ponownie prosi o hasło przed wprowadzeniem zmian. Z tego powodu nagłówek strony może wyświetlać komunikat "Limited access" do momentu podniesienia uprawnień.

Taka konstrukcja ma konsekwencje w systemach o zaostrzonych zabezpieczeniach. Jeśli użytkownik skonfigurował logowanie SSH wyłącznie przy użyciu kluczy z wyłączonym uwierzytelnianiem hasłem, konto może nie posiadać aktywnego hasła. W rezultacie logowanie do Cockpit jest odrzucane, mimo że ssh nadal działa. Należy to sprawdzić na serwerze:

sudo passwd -S deploy

Dane wyjściowe rozpoczynające się od deploy L oznaczają, że hasło jest zablokowane, więc PAM nie może go zweryfikować i żadne wpisane hasło nie zadziała. P oznacza, że ustawione jest poprawne hasło. Strona logowania Cockpit nie obsługuje kluczy SSH. Klucze są używane tylko wtedy, gdy Cockpit łączy się z maszyny, do której użytkownik jest zalogowany, z innym hostem.

Webmin przechowuje własnych użytkowników w /etc/webmin/miniserv.users, oddzielnie od /etc/passwd, ale można go również skonfigurować do uwierzytelniania za pomocą kont Unix. Użytkownik Webmin, któremu przyznano dostęp do wszystkich modułów, posiada uprawnienia root na danej maszynie, niezależnie od ustawień powłoki logowania. Webmin posiada wbudowaną obsługę TOTP (time-based one-time password) oraz własny mechanizm blokowania hostów po wielokrotnych nieudanych próbach logowania; obie funkcje włącza się w sekcji Webmin Configuration. Cockpit obsługuje drugi składnik uwierzytelniania tylko w przypadku dodania go do PAM, na przykład za pomocą libpam-google-authenticator.

Sposób aktualizacji poszczególnych komponentów

Cockpit jest dostarczany w pakietach przez dystrybucję. W systemie Ubuntu 24.04 pochodzi on z oficjalnego repozytorium, jednak projekt zaleca korzystanie z kanału backports w celu uzyskania nowszej wersji:

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

apt policy wyświetla zainstalowaną wersję oraz repozytorium, z którego pochodzi. Jeśli w backports nie ma nowszej wersji, apt automatycznie wybierze wersję z głównego repozytorium, co jest rozwiązaniem poprawnym. cockpit.socket powinno wskazywać active (listening). Poprawki bezpieczeństwa są następnie dostarczane w ramach tego samego procesu unattended-upgrades, co aktualizacje jądra, od wydawcy, któremu już ufasz.

Webmin nie znajduje się w repozytoriach Ubuntu. Oficjalna instalacja wymaga najpierw dodania własnego repozytorium Webmin oraz klucza podpisu:

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

Przed uruchomieniem skryptu należy zapoznać się z jego treścią, ponieważ wykonuje on operacje z uprawnieniami root. Od tego momentu każde polecenie apt upgrade na serwerze pobiera pakiety również z repozytorium Webmin, co oznacza dodanie drugiego wydawcy z pełnym zaufaniem na poziomie root. Jest to rzeczywisty koszt korzystania z Webmin, co warto zilustrować przykładem: CVE-2019-15107 było backdoorem w kilku pakietach wersji 1.9x, który umożliwiał nieuwierzytelnione wykonywanie poleceń. Luka dotarła do użytkowników, ponieważ serwer budujący pakiety projektu został przejęty, a nie samo repozytorium kodu źródłowego. Pakowanie przez dystrybucję nie eliminuje całkowicie takiego ryzyka. Dodaje jednak etap budowania i weryfikacji, którym nie musisz zarządzać samodzielnie.

Dlaczego żadne z nich nie powinno działać na publicznym porcie

Cockpit nasłuchuje na porcie TCP 9090, a Webmin na TCP 10000, oba z wykorzystaniem TLS (transport layer security) oraz certyfikatu z podpisem własnym, co powoduje wyświetlenie ostrzeżenia w przeglądarce. Tworzenie i zaufanie certyfikatowi z podpisem własnym wyjaśnia, co to ostrzeżenie oznacza, a czego nie. Oba porty są stale skanowane, a oba panele zapewniają dostęp do konta root, więc odgadnięcie lub ponowne użycie hasła oznacza pełne przejęcie serwera.

Bezpiecznym wzorcem jest powiązanie panelu z localhost i uzyskiwanie do niego dostępu poprzez tunel SSH. W przypadku Cockpit należy nadpisać jednostkę socket:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

Pusta linia ListenStream= jest wymagana. systemd dopisuje wartości do list ustawień, więc bez niej jednostka zachowałaby oryginalne 0.0.0.0:9090 i dodała nowy adres, przez co panel pozostałby publiczny. Zastosuj nadpisanie i sprawdź, co nasłuchuje:

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

Wynik musi wskazywać 127.0.0.1:9090. Adres *:9090 lub 0.0.0.0:9090 oznacza, że nadpisanie nie weszło w życie. Teraz otwórz tunel ze swojej maszyny i przejdź pod adres https://localhost:9090:

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

Utrzymuj lokalny port zgodny z portem zdalnym. Cockpit porównuje nagłówek Origin przeglądarki z adresem, który według niego jest obsługiwany, więc tunel z lokalnego portu 9999 załaduje stronę logowania, ale nie pozwoli się zalogować, a journalctl -u cockpit odnotuje odrzucone źródło. Jeśli potrzebujesz innego portu lokalnego, określ go w /etc/cockpit/cockpit.conf:

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

Zrestartuj za pomocą sudo systemctl restart cockpit.socket, aby wprowadzić zmiany. Dla Webmin równoważne ustawienie znajduje się w /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 również sprawdza nagłówek Referer przy przesyłaniu formularzy i odrzuca żądania, które wydają się pochodzić z innego hosta, co powoduje błędy przy pierwszej próbie użycia reverse proxy. Linia referers= w tym samym pliku pozwala na zdefiniowanie nazwy hosta proxy, a webprefix= służy do poinformowania Webmin, że działa on pod określoną ścieżką.

Uwierzytelnione reverse proxy to druga opcja: nginx z przodu, z warstwą logowania jednokrotnego Authentik. To rozwiązanie działa i jest drugie w kolejności pod względem bezpieczeństwa. Panel nadal działa jako root za proxy, a użytkownik musi utrzymywać dwa punkty wejścia zamiast jednego. Tunel nie dodaje żadnej usługi nasłuchującej do Internetu i wykorzystuje już zabezpieczony klucz SSH.

Który panel wybrać na serwerze z działającymi usługami produkcyjnymi

Cockpit, z dwóch powodów istotnych, gdy inni użytkownicy polegają na danej maszynie. Jest on aktywowany przez gniazdo (socket activated), więc cockpit-ws działa tylko wtedy, gdy otwarta jest sesja i nie ma stałego demona root oczekującego na porcie. Ponadto nie przejmuje on kontroli nad niczym: usunięcie pakietu sprawia, że każda usługa działa dokładnie tak samo jak wcześniej, ponieważ Cockpit nie przechowuje własnych konfiguracji. Proces miniserv.pl w Webmin pozostaje rezydentny niezależnie od tego, czy ktoś jest zalogowany. Sprawdź koszt zasobów swojego panelu za pomocą systemctl status webmin, co wyświetli pamięć rezydentną uruchomionego procesu.

Jeśli potrzebujesz modułów DNS lub poczty z Webmin, wydziel dla nich osobny serwer. Serwer z Webmin wykonujący jedno zadanie, powiązany z 127.0.0.1, stanowi ograniczone ryzyko. Webmin współdzielący hosta z aplikacją dostępną dla klientów takim ryzykiem nie jest. Wykonaj prace podstawowe przed instalacją któregokolwiek z paneli: pierwsze dziesięć minut na nowym VPS obejmuje konfigurację użytkownika bez uprawnień root oraz firewalla, których obecność zakładają oba panele.

Gdy odpowiedź nie jest jednoznaczna

Panel jest rozwiązaniem przypisanym do konkretnego serwera i wymaga obsługi ręcznej, nie pozostawiając przy tym żadnego śladu tego, co i dlaczego zostało zmienione. W przypadku jednej maszyny jest to akceptowalne. Przy pięciu serwerach praca staje się powtarzalna, a przy dwudziestu zaczyna się zgadywanie, na którym z nich pominięto zmianę. Cockpit pozwala na dodanie innych hostów do jednej sesji przez SSH, jednak nowsze wersje domyślnie wyłączają tę funkcjonalność, wymagając AllowMultiHost=yes w /etc/cockpit/cockpit.conf, a i tak zmuszają użytkownika do ręcznego wprowadzania tych samych zmian wielokrotnie.

Alternatywą jest standardowe SSH z konfiguracją przechowywaną w repozytorium git. Zarządzanie wieloma serwerami Linux z jednego miejsca opisuje strukturę takiej konfiguracji, a pierwszy playbook Ansible pozwala zastosować tę samą regułę firewalla do każdego hosta z poziomu jednego pliku, który można zweryfikować za pomocą diff. Praca z kontenerami wygląda podobnie: docker compose up -d przez SSH z pliku w git, zgodnie z podstawami Docker Compose, jest skuteczniejsze niż klikanie w panelu, a Cockpit w ogóle nie służy do zarządzania Docker.

Panelu należy używać do zadań, w których terminal się nie sprawdza, takich jak odczytywanie wykresów metryk czy identyfikacja, która z czterdziestu jednostek uległa awarii. Do wszystkiego, co wykonuje się więcej niż dwa razy, należy używać kodu.

Tryby awarii i komunikaty, które zobaczysz

Cockpit odrzuca hasło, które jest akceptowane przez SSH. Konto wymaga klucza. sudo passwd -S alice wyświetla L w drugim polu, więc PAM nie otrzymuje hasła do weryfikacji. Ustaw hasło za pomocą sudo passwd alice lub zachowaj to konto wyłącznie do SSH, a do Cockpit zaloguj się jako inny użytkownik.

Cockpit odmawia dostępu dla root, mimo poprawnego hasła. /etc/cockpit/disallowed-users zawiera root. Zaloguj się jako zwykły użytkownik z uprawnieniami sudo. Jest to zamierzony mechanizm, ponieważ polkit rejestruje wtedy, który użytkownik dokonał eskalacji uprawnień.

Cockpit nie wyświetla stron Networking lub Firewall. Strony te wymagają obecności NetworkManager oraz firewalld. VPS z systemem Ubuntu korzysta z netplan wraz z systemd-networkd oraz ufw, dlatego strony te nie są widoczne. Nie oznacza to awarii; rozwiązaniem jest dalsze korzystanie z ufw za pośrednictwem SSH.

Strona logowania Cockpit ładuje się przez tunel, ale logowanie kończy się niepowodzeniem. Lokalny port różni się od portu zdalnego, przez co weryfikacja Origin kończy się błędem, co odnotowuje journalctl -u cockpit. Dopasuj porty lub ustaw Origins w pliku /etc/cockpit/cockpit.conf.

Formularze Webmin nie działają po umieszczeniu panelu za proxy. Mechanizm weryfikacji Referer odrzuca żądania. Dodaj nazwę hosta proxy do referers= w pliku /etc/webmin/miniserv.conf oraz ustaw webprefix=, jeśli panel jest serwowany w podkatalogu.

Brak pewności, czy panel jest wystawiony na zewnątrz. sudo ss -lntp | grep -E '9090|10000' udziela odpowiedzi na to pytanie z poziomu serwera, a Webmin zapisuje każdą próbę logowania w /var/webmin/miniserv.log, co warto sprawdzić po każdej zmianie sposobu nasłuchiwania usługi.

FAQ

Czy Cockpit czy Webmin jest lepszy dla pojedynczego VPS z Ubuntu?

Dla większości użytkowników lepszy jest Cockpit, ponieważ pochodzi z oficjalnych repozytoriów Ubuntu, jest aktualizowany wraz z resztą systemu i działa tylko wtedy, gdy otwarta jest sesja przeglądarki. Wybierz Webmin, jeśli potrzebujesz edytora opartego na formularzach dla usługi, której Cockpit nie obsługuje, takiej jak BIND lub Postfix. W zamian zaakceptuj fakt, że jego serwer WWW działa stale z uprawnieniami root, a aktualizacje pochodzą z zewnętrznego repozytorium Webmin.

Czy mogę uruchomić Cockpit i Webmin na tym samym serwerze?

Tak. Używają różnych portów, 9090 oraz 10000, więc nie wchodzą w konflikt, ponieważ oba narzędzia edytują system bezpośrednio, zamiast przejmować nad nim kontrolę. Jest to jednak niekorzystne rozwiązanie. Każdy panel stanowi oddzielny punkt dostępu z uprawnieniami root na tej samej maszynie, co podwaja ryzyko przy niewielkiej oszczędności czasu. Jeśli zainstalujesz oba, powiąż je z 127.0.0.1 i uzyskuj do nich dostęp przez tunel SSH.

Czy bezpieczne jest otwieranie portu 9090 lub 10000 na świat?

Nie przy logowaniu hasłem. Oba panele prowadzą do konta root, a oba porty są wykrywane przez rutynowe skanowanie w ciągu kilku godzin od otwarcia. Powiąż panel z 127.0.0.1, następnie uruchom ssh -N -L 9090:127.0.0.1:9090 user@host i przejdź pod adres https://localhost:9090. Potwierdź za pomocą sudo ss -lntp | grep 9090, co musi zwrócić 127.0.0.1:9090 zamiast 0.0.0.0:9090. Uwierzytelnione reverse proxy jest akceptowalną drugą opcją.

Dlaczego logowanie do Cockpit kończy się niepowodzeniem, skoro SSH z kluczem działa?

Cockpit uwierzytelnia się przez PAM przy użyciu hasła systemowego, a jego strona logowania nie akceptuje kluczy SSH. Na zabezpieczonym serwerze konto często nie posiada ustawionego hasła. Uruchom sudo passwd -S youruser: znak L w drugim polu oznacza, że hasło jest zablokowane, więc PAM nie ma czego zaakceptować i każda próba jest odrzucana. Ustaw hasło za pomocą sudo passwd youruser lub użyj innego konta do obsługi panelu.

Czy Cockpit zarządza kontenerami Docker?

Nie. Strona kontenerów w Cockpit pochodzi z cockpit-podman i zarządza narzędziem Podman. Stary moduł Docker został usunięty lata temu i nie wróci. Jeśli Twoje usługi działają w Docker, zarządzaj nimi za pomocą pliku compose w systemie kontroli wersji przez SSH, a Cockpit niech obsługuje system wokół nich, taki jak dziennik systemowy czy dyski.