Cockpit или Webmin: что выбрать для управления сервером

Cockpit или Webmin: краткий ответ

Cockpit и Webmin — это веб-панели для управления сервером Linux через браузер, и они решают разные задачи. Cockpit поставляется в официальных репозиториях вашего дистрибутива и взаимодействует с системой через systemd, journald, polkit и udisks, поэтому он отображает состояние сервера, которым вы по-прежнему управляете по SSH. Webmin старше и обладает гораздо более широким функционалом: он редактирует конфигурационные файлы Apache, BIND, Postfix, MariaDB и десятков других сервисов, с которыми Cockpit не работает, и для этого запускает собственный веб-сервер с правами root.

Устанавливайте Cockpit, если вам нужен мониторинг одного сервера в реальном времени, просмотр логов и терминал для экстренных случаев. Устанавливайте Webmin, если вам нужен графический интерфейс для настройки сервиса, который вы не хотите конфигурировать вручную. Не открывайте доступ к обеим панелям через публичный порт с авторизацией по паролю. Если вы уже управляете более чем двумя или тремя серверами, честный ответ часто заключается в том, что не стоит использовать ни одну из них, так как связка SSH и Ansible масштабируется лучше, чем любая панель.

Что именно можно изменить в каждой панели

Базовая установка Cockpit занимает мало места, а большинство функций вынесены в отдельные пакеты, которые можно не устанавливать:

• службы и таймеры systemd: запуск, остановка, включение и чтение файла юнита
• журнал (journal), с фильтрацией по юниту и приоритету, который доступен через journalctl с выбором даты
• локальные учетные записи, членство в группах и авторизованные SSH-ключи
• хранилище с помощью cockpit-storaged: разделы, группы томов LVM, файловые системы и точки монтирования
• контейнеры с помощью cockpit-podman, который управляет только Podman
• обновление пакетов с помощью cockpit-packagekit
• графики CPU, памяти, диска и сети с помощью cockpit-pcp
• root-терминал во вкладке браузера

Два раздела на Ubuntu VPS выглядят нерабочими, но это не так. Страница Networking в Cockpit — это интерфейс для NetworkManager, а образы Ubuntu Server используют netplan с systemd-networkd, поэтому страница отсутствует или пуста. Не устанавливайте 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 после сохранения формы покажет, что именно записал модуль. Это не отображает действия, которые запускают команды или выполняют SQL (как в модулях MariaDB и PostgreSQL), а также запись в файлы вне /etc. В этих пределах это самый быстрый способ понять, что именно делает страница Webmin. Руководство по установке Webmin и первому входу подробно описывает дерево модулей. Virtualmin и Usermin — это отдельные продукты на том же движке, предназначенные для виртуального хостинга и конечных пользователей; они наследуют все упомянутые здесь особенности безопасности.

Механизмы аутентификации

У Cockpit нет собственной базы пользователей. Страница входа использует стек PAM (pluggable authentication modules) в /etc/pam.d/cockpit, поэтому учетные записи и пароли соответствуют системным пользователям Unix. Вход под root по умолчанию запрещен, так как этот пользователь указан в /etc/cockpit/disallowed-users. Привилегированные действия выполняются через polkit, и интерфейс запрашивает пароль повторно перед внесением изменений. Именно поэтому в заголовке страницы может отображаться «Limited access», пока вы не повысите свои права.

Такая архитектура имеет особенность, с которой сталкиваются при настройке защищенных серверов. Если вы настроили вход по SSH только с использованием ключей при отключенной аутентификации по паролю, у учетной записи может не быть действующего пароля. В этом случае вход в Cockpit будет отклонен, хотя ssh продолжит работать. Проверьте это на сервере:

sudo passwd -S deploy

Вывод, начинающийся с deploy L, означает, что пароль заблокирован. PAM не может принять данные, и любой введенный пароль будет неверным. P означает, что установлен действующий пароль. Страница входа Cockpit не поддерживает SSH-ключи. Ключи используются только тогда, когда Cockpit устанавливает соединение с другого узла, к которому вы уже подключились.

Webmin хранит собственных пользователей в /etc/webmin/miniserv.users, отдельно от /etc/passwd, но его можно настроить на аутентификацию через учетные записи Unix. Пользователь Webmin, которому предоставлен доступ ко всем модулям, получает права root на этой машине, независимо от настроек его командной оболочки. Webmin поставляется со встроенной поддержкой TOTP (time-based one-time password) и функцией блокировки хостов после нескольких неудачных попыток входа; обе функции активируются в разделе Webmin Configuration. Cockpit получает второй фактор аутентификации только в том случае, если вы добавите его в PAM, например, с помощью libpam-google-authenticator.

Как обновляется каждый из них

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 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 (transport layer security) с самоподписанным сертификатом, поэтому первое, что вы видите — предупреждение браузера. Создание и доверие к самоподписанному сертификату объясняет, что это предупреждение означает, а что нет. Оба порта постоянно сканируются, и обе панели предоставляют доступ к root, поэтому угаданный или повторно использованный пароль означает полный взлом сервера.

Безопасный подход — привязать панель к localhost и обращаться к ней через SSH-туннель. Для Cockpit переопределите юнит сокета:

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 на основе заголовка Host, который отправляет браузер, поэтому туннель с локального порта 9999, открытый на https://localhost:9999, проходит ту же проверку, так как заголовки браузера Host и Origin указывают на один и тот же адрес. Проверка не проходит, если что-то между браузером и Cockpit изменяет Host, например, reverse proxy, который не передает исходный заголовок. Страница входа загружается, но авторизация не удается, и cockpit-ws записывает received request from bad Origin. Эта строка находится в журнале юнитов cockpit-wsinstance-https@, а не cockpit.service, поэтому читайте её с помощью sudo journalctl -u 'cockpit-wsinstance-https@*'. Чтобы разрешить публичный адрес, который отличается от того, что видит Cockpit, укажите его в /etc/cockpit/cockpit.conf:

[WebService]
Origins = https://panel.example.com

Перезапустите с помощью sudo systemctl restart cockpit, чтобы применить изменения. Для 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 при отправке форм и отклоняет запросы, которые, по его мнению, приходят с другого хоста, что и ломает первую попытку настройки reverse proxy. Строка referers= в /etc/webmin/config — это место, где вы разрешаете имя хоста прокси, а webprefix= в том же файле указывает Webmin, что он работает по определенному пути.

Аутентифицированный reverse proxy — это другой вариант: nginx на переднем плане с слоем единого входа Authentik для авторизации. Это работает, и это второй по предпочтительности вариант. Панель по-прежнему работает от имени root за прокси, и теперь вы обслуживаете две входные точки вместо одной. Туннель не добавляет в интернет никаких прослушивающих сервисов и повторно использует SSH-ключ, который вы уже защищаете.

Какую панель выбрать для сервера, на котором уже работают продуктовые сервисы

Cockpit, по двум причинам, которые важны, когда от машины зависят другие люди. Она активируется через сокет, поэтому cockpit-ws работает только во время открытой сессии, и в системе нет постоянно запущенного root-демона, ожидающего соединений на порту. Кроме того, она ничего не контролирует: удалите пакет, и все сервисы продолжат работать точно так же, как и раньше, поскольку Cockpit не хранит собственных конфигураций. Процесс miniserv.pl в Webmin остается резидентным независимо от того, вошел кто-то в систему или нет. Проверьте, сколько ресурсов потребляет ваш экземпляр с помощью systemctl status webmin, которая выводит объем резидентной памяти запущенного процесса.

Если вам нужны модули DNS или почты из Webmin, выделите под них отдельный сервер. Сервер с Webmin, выполняющий одну задачу и привязанный к 127.0.0.1, представляет собой изолированный риск. Webmin, работающий на одном хосте с вашим клиентским приложением, — нет. Выполните базовую настройку до установки любой из панелей: первые десять минут на новом VPS охватывают создание пользователя без прав root и настройку межсетевого экрана, наличие которых подразумевают обе панели.

Когда ответ — ни то, ни другое

Панель управления привязана к конкретному серверу и требует ручного вмешательства, не оставляя записей о том, что именно и почему было изменено. Это приемлемо для одного узла. При наличии пяти серверов вы начинаете повторять одни и те же действия, а при двадцати — гадаете, на каком из них пропустили изменение. Cockpit позволяет добавить другие хосты в одну сессию по SSH, но этот переключатель хостов считается устаревшим начиная с Cockpit 322. Его доступность по умолчанию теперь зависит от дистрибутива, и там, где он отключен, требуется AllowMultiHost=yes в /etc/cockpit/cockpit.conf. Даже если он включен, вам всё равно приходится пять раз выполнять одни и те же действия вручную.

Альтернативой является обычный SSH с конфигурацией, хранящейся в git-репозитории. В Управление несколькими серверами Linux из одного места описана структура такой настройки, а в первом Ansible playbook показано, как применить одно правило межсетевого экрана ко всем хостам из файла, который можно проверить через diff. Работа с контейнерами строится аналогично: docker compose up -d по SSH на основе файла из git, как описано в руководстве по основам Docker Compose, эффективнее, чем работа через любую панель, к тому же Cockpit изначально не предназначен для управления Docker.

Используйте панель для задач, с которыми терминал справляется плохо, например, для просмотра графиков метрик или поиска того, какой из сорока юнитов завершился с ошибкой. Используйте код для всего, что вам приходится делать чаще двух раз.

Типичные сбои и сообщения об ошибках

Cockpit отклоняет пароль, который принимает SSH. Учетная запись настроена только на использование ключей. 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. На VPS с Ubuntu используется netplan вместе с systemd-networkd и ufw, поэтому данные страницы не отображаются. Это не является неисправностью; решение заключается в дальнейшем использовании ufw через SSH.

Страница входа Cockpit загружается через прокси, но авторизация не проходит. Прокси изменил заголовок Host, из-за чего проверка Origin завершается неудачей, а sudo journalctl -u 'cockpit-wsinstance-https@*' выводит received request from bad Origin. Передавайте исходный заголовок Host или укажите Origins в файле /etc/cockpit/cockpit.conf. Обычный SSH-туннель не вызывает этой проблемы, независимо от выбранного локального порта.

Отправка форм в Webmin завершается ошибкой после размещения за прокси. Проверка Referer отклоняет запросы. Добавьте имя хоста прокси в referers= в файле /etc/webmin/config и установите webprefix= в том же файле, если панель доступна по определенному пути.

Вы не уверены, открыта ли панель вовне. sudo ss -lntp | grep -E '9090|10000' позволяет проверить это непосредственно с сервера, а Webmin записывает каждую попытку входа в /var/webmin/miniserv.log. Рекомендуется просматривать этот файл после любого изменения параметров прослушивания портов.

FAQ

Что лучше для одного VPS на Ubuntu: Cockpit или Webmin?

Для большинства пользователей лучше Cockpit, так как он входит в официальные репозитории Ubuntu, обновляется вместе с системой и работает только во время активной сессии в браузере. Выбирайте Webmin, если вам нужен графический редактор для сервисов, которые не поддерживает Cockpit (например, BIND или Postfix). Учитывайте, что веб-сервер Webmin постоянно работает от имени root, а обновления приходят из собственного репозитория проекта.

Можно ли запускать 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: команда должна вернуть 127.0.0.1:9090, а не 0.0.0.0:9090. Допустимой альтернативой является использование обратного прокси с аутентификацией.

Почему вход в Cockpit не работает, хотя SSH по ключу проходит?

Cockpit проходит аутентификацию через PAM с использованием пароля пользователя Unix, а страница входа не поддерживает SSH-ключи. На защищённом сервере у учётной записи часто нет установленного пароля. Выполните sudo passwd -S youruser: символ L во втором поле означает, что пароль заблокирован, поэтому PAM не может принять данные для входа. Установите пароль с помощью sudo passwd youruser или используйте для панели другую учётную запись.

Управляет ли Cockpit контейнерами Docker?

Нет. Страница контейнеров в Cockpit работает через cockpit-podman и предназначена для управления Podman. Старый модуль для Docker был удалён много лет назад и не вернётся. Если ваши сервисы работают в Docker, управляйте ими через compose-файлы в системе контроля версий по SSH, а Cockpit используйте для обслуживания системы: просмотра журналов и управления дисками.