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: запуск, остановка, включение и чтение файла юнита
• журнал, фильтруемый по юниту и приоритету, который доступен через 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 после сохранения формы покажет именно то, что записал модуль. Это самый быстрый способ понять, что на самом деле делает любая страница 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 выводит установленную версию и репозиторий, из которого она была получена. Если в 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 браузера с адресом, который, как он считает, обслуживает. Поэтому туннель с локального порта 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 при отправке форм и отклоняет запросы, которые, по его мнению, приходят с другого хоста; именно это ломает первую попытку настройки reverse proxy. Строка referers= в том же файле позволяет указать имя хоста прокси, а 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, но в последних версиях эта возможность отключена по умолчанию и требует 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 загружается через туннель, но авторизация не проходит. Ваш локальный порт отличается от удаленного, поэтому проверка Origin завершается неудачей, а journalctl -u cockpit отображает это. Приведите порты в соответствие или укажите Origins в /etc/cockpit/cockpit.conf.

Отправка форм в Webmin завершается ошибкой после размещения за прокси-сервером. Проверка Referer отклоняет запросы. Добавьте имя хоста прокси-сервера в referers= в файле /etc/webmin/miniserv.conf и установите 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 используйте для обслуживания системы: просмотра журналов и управления дисками.