Termix на VPS: веб-SSH вместо Termius

Задача: подключиться к серверу с любого устройства

У человека, который арендует хотя бы пару VPS, довольно быстро появляется одна и та же проблема. Ключи и список серверов лежат на рабочем ноутбуке. С телефона в дороге зайти неудобно. На чужом компьютере — нечем: ставить туда SSH-клиент и копировать приватный ключ никто в здравом уме не станет. А если ноутбук потеряется, вместе с ним потеряется и вся «карта» инфраструктуры.

Классический ответ — Termius: красивый клиент под все платформы, который синхронизирует хосты и ключи между устройствами. Но синхронизация в нём платная. В бесплатном тарифе Starter есть SSH, SFTP и проброс портов, а вот облачное хранилище и синхронизация между мобильным и десктопом — это тариф Pro за 10 $ в месяц при годовой оплате. Плюс два неприятных нюанса: ваши ключи оказываются в чужом облаке, а оплатить зарубежную подписку из России в 2026-м — отдельный квест.

Второй распространённый ответ — поставить на сервер что-нибудь вроде ttyd или wetty, которые отдают терминал в браузер. Это работает, но решает только половину задачи: терминал есть, а менеджера хостов, хранилища ключей, файлового менеджера и туннелей — нет. И, что важнее, такие инструменты обычно отдают шелл того сервера, на котором стоят, а не позволяют ходить с него на другие машины.

Проект написан на React и Node.js, лежит под лицензией Apache 2.0, к августу 2026 набрал почти 15 тысяч звёзд на GitHub и обновляется буквально каждый день. Актуальная версия на момент написания — 2.6.1 от 6 августа 2026. Дальше в статье все команды и все названия пунктов интерфейса проверены на реально развёрнутой установке именно этой версии.

Чем Termix отличается от соседей по нише

«Терминал в браузере» — это несколько разных категорий инструментов, которые легко перепутать. Короткая карта, чтобы не поставить не то:

Отдельно стоит сказать про Docker внутри Termix. Он умеет показывать контейнеры на подключённых серверах, запускать, останавливать и удалять их, смотреть статистику и логи, заходить внутрь через docker exec. Но создавать стеки он не умеет — авторы прямо пишут в описании, что не пытались заменить Portainer и Dockge. Если вам нужен и полноценный деплой, посмотрите наш разбор Docker Compose на VPS.

Сразу о главном риске

Прежде чем ставить — поймите, что вы делаете. Termix собирает в одном месте доступ ко всем вашим серверам: адреса, логины, пароли и приватные ключи. Тот, кто войдёт в панель, автоматически получит рутовый доступ ко всей вашей инфраструктуре. Это не повод не ставить, это повод настроить правильно.

Самый надёжный вариант — вообще не публиковать Termix в интернет, а поднять WireGuard и ходить в панель только через VPN. Тогда снаружи у сервера открыт один UDP-порт, и перебирать пароли просто некому. Ниже мы всё-таки разберём вариант с публичным доменом — он нужен, если хочется заходить с чужого устройства, где VPN не поставить, — но если такой задачи нет, VPN лучше.

Что понадобится

Если Docker ещё не стоит, ставим его одной командой с официального скрипта:

curl -fsSL https://get.docker.com | sudo sh

Проверяем, что всё на месте — команда должна показать версию 2.x:

sudo docker compose version

Шаг 1. Запускаем Termix

Создаём каталог для проекта и файл описания:

sudo mkdir -p /opt/termix && cd /opt/termix

services:
  termix:
    image: ghcr.io/lukegus/termix:latest
    container_name: termix
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - termix-data:/app/data
    environment:
      PORT: "8080"
      ENABLE_TELEMETRY: "false"
      GUACD_HOST: "guacd"
      GUACD_TUNNEL_HOST: "termix"
      GUACD_RECORDING_PATH: "/termix-data/session_recordings/guacamole"
    depends_on:
      - guacd
    networks:
      - termix-net

  guacd:
    image: guacamole/guacd:1.6.0
    container_name: guacd
    restart: unless-stopped
    volumes:
      - termix-data:/termix-data
    networks:
      - termix-net

volumes:
  termix-data:
    driver: local

networks:
  termix-net:
    driver: bridge

Разберём места, которые важны и которые легко испортить.

• 127.0.0.1:8080:8080 — панель слушает только сам сервер. Наружу её выпустит Nginx, который мы поставим следующим шагом. В примерах из документации Termix стоит просто 8080:8080: так панель окажется открыта всему интернету ещё до того, как вы успеете завести пароль.
• PORT: "8080" — порт внутри контейнера, менять его незачем. Если 8080 на сервере уже занят, правьте левую часть строки портов, например 127.0.0.1:9090:8080. А если всё-таки меняете PORT, не берите значения из диапазона 30001–30005 — они заняты внутренними службами Termix.
• guacd — отдельный контейнер, движок Apache Guacamole. Он нужен только для удалённого рабочего стола по RDP, VNC и Telnet; SSH, файлы и туннели работают без него. Если удалённый рабочий стол не нужен, удалите весь сервис guacd, строки depends_on, три переменные GUACD_*, оба упоминания networks и блок networks в конце файла — сеть Compose создаст сам.
• Порт guacd (4822) наружу не пробрасывается специально. В примере из документации проекта он опубликован на хосте, но это лишнее: Termix ходит к нему по внутренней docker-сети, а открытый 4822 — просто ещё одна дверь снаружи.
• ENABLE_TELEMETRY: "false" отключает анонимную статистику, которую Termix иначе отправляет раз в сутки. Строку можно убрать, если вы не против помочь проекту цифрами.

Запускаем:

sudo docker compose up -d

Первый старт занимает секунд двадцать: Termix генерирует ключи шифрования, создаёт базу и докачивает вспомогательный бинарник. Убедиться, что всё поднялось, можно по логам:

sudo docker compose logs -f termix

Ищем в выводе две строки — версию и сообщение об успешном старте. В реальном логе перед ними стоит время, а после — служебные пометки. Увидели — можно нажать Ctrl+C:

[INFO] [📦] Termix Backend starting - Version: 2.6.1
[SUCCESS] [🚀] Termix backend started successfully

Шаг 2. Домен и HTTPS

Перед этим шагом убедитесь, что A-запись вашего домена уже указывает на IP сервера — иначе certbot не сможет выпустить сертификат. Ставим веб-сервер и клиент Let's Encrypt:

sudo apt update && sudo apt install -y nginx certbot python3-certbot-nginx

Создаём конфиг сайта. Замените termix.example.com на свой домен:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name termix.example.com;

    client_max_body_size 5G;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_buffering off;
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
    }
}

Здесь четыре места, без которых что-нибудь обязательно сломается:

• Блок map вместе с заголовками Upgrade и Connection пропускает веб-сокет. Без них интерфейс откроется как ни в чём не бывало, а терминал будет бесконечно «подключаться»: сервер вернёт ошибку 426 Upgrade Required. Это самая частая ошибка при настройке Termix.
• client_max_body_size 5G — лимит на размер загружаемого файла. Стандартный лимит Nginx — один мегабайт, и файловый менеджер на файле в три мегабайта отвалится с ошибкой 413. Пять гигабайт — столько же разрешает внутренний Nginx самого Termix.
• proxy_read_timeout 86400s — сутки. Иначе Nginx оборвёт открытую вкладку терминала через минуту простоя, и вы будете постоянно переподключаться.
• proxy_buffering off — чтобы вывод команд появлялся сразу, а не порциями.

Блок map объявляется вне server — так и должно быть. Если точно такой же блок уже есть в конфиге другого вашего сайта, ничего страшного: Nginx разрешает повторное объявление.

Включаем конфиг, проверяем синтаксис и выпускаем сертификат:

sudo ln -s /etc/nginx/sites-available/termix /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d termix.example.com

Certbot спросит почту, попросит согласиться с условиями и предложит включить перенаправление с HTTP на HTTPS — соглашайтесь. Он сам допишет блок с сертификатом в конфиг и настроит автопродление.

Закрываем файрвол. Наружу нужны только SSH и веб:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

Шаг 3. Первый вход и закрытие регистрации

Открываем https://termix.example.com. Termix увидит, что пользователей ещё нет, и предложит создать первого. Первый созданный пользователь автоматически становится администратором — так что не тяните и заведите его сразу, пока это не сделал кто-то другой.

Сразу после входа — самое важное действие во всей установке. Нажмите на своё имя пользователя внизу слева, откройте «Настройки администратора», вкладка «Общие», и выключите переключатель «Разрешить регистрацию пользователей». Пока он включён, любой, кто откроет ваш адрес, заведёт себе учётку.

      ALLOW_REGISTRATION: "false"

Второе обязательное действие — двухфакторная аутентификация. Профиль пользователя, раздел «Безопасность», пункт «Аутентификатор TOTP» и кнопка «Настроить TOTP». Termix покажет QR-код: отсканируйте его любым приложением-аутентификатором, введите шестизначный код для подтверждения и обязательно сохраните резервные коды — кнопка «Скачать резервные коды». Каждый из них срабатывает один раз и понадобится, если вы потеряете телефон.

Заодно можно переключить интерфейс на русский: там же, в профиле, пункт «Язык». В версии 2.6 встроено около 30 языков.

Если потеряли пароль от панели

Восстановление устроено необычно, и это стоит знать заранее. На странице входа есть запрос сброса пароля, но код никуда не отправляется — Termix пишет его прямо в лог контейнера. Достать его можно с сервера по SSH:

cd /opt/termix
sudo docker compose logs termix | grep "reset code"

В логе появится строка вида Password reset code generated for user admin: 435920. Код действует 15 минут.

Пускать только со своих адресов

Перебор паролей Termix отбивает сам: после пяти неудачных попыток вход блокируется на десять минут — по IP и по имени пользователя одновременно. Мы это проверили: шестая попытка возвращает «Too many login attempts» и время до разблокировки. Отдельный Fail2Ban ставить не нужно.

Но если у вас статический IP дома или на работе, надёжнее просто не пускать всех остальных. Добавьте две строки в начало блока location / в конфиге Nginx:

        allow 203.0.113.5;
        deny all;

Вместо 203.0.113.5 — ваш адрес; строк allow может быть несколько, можно указывать и подсети вида 198.51.100.0/24. Все остальные получат 403 и даже не увидят страницу входа. Продлению сертификата это не мешает: проверочный запрос Let's Encrypt идёт в отдельную, более точную локацию — мы специально проверили, что при deny all в location / она продолжает отвечать.

Не забудьте применить: sudo nginx -t && sudo systemctl reload nginx. И держите под рукой доступ по SSH — если адрес сменится, вернуть себе панель можно будет только через правку конфига на сервере.

Шаг 4. Добавляем первый сервер

Открываем «Менеджер хостов» — кнопка вверху слева — и нажимаем «Добавить хост». Заполняем адрес, порт, имя пользователя и способ входа. Ниже в форме есть переключатели, какие возможности включить для этого сервера: «Включить терминал», «Включить файловый менеджер», туннели, Docker, метрики. Включайте только то, чем реально будете пользоваться — меньше включено, меньше поверхность атаки.

Дальше сервер открывается во вкладке. Вкладок можно держать сколько угодно, а экран — делить на четыре панели одновременно. Есть удобная мелочь: двойное нажатие левого Shift открывает поиск по хостам, чтобы подключиться, не отрывая рук от клавиатуры.

Шаг 5. SSH-ключи вместо паролей

Вписывать пароль в каждый хост — плохая идея, тем более что серверы правильнее вообще закрыть от входа по паролю (об этом — в статье про безопасность VPS). В Termix для этого есть раздел «Учётные данные»: вы один раз добавляете приватный ключ, а потом просто выбираете его в настройках любого хоста.

Если ключа ещё нет, создайте его на своей машине — современный стандарт это ed25519:

ssh-keygen -t ed25519 -C "termix"

Публичную часть (~/.ssh/id_ed25519.pub) кладём на серверы обычным способом:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@IP_СЕРВЕРА

Приватную часть (файл id_ed25519 без расширения) добавляем в Termix: «Учётные данные» → «Добавить учётные данные», тип «SSH-ключ», вставляем содержимое файла или загружаем его кнопкой «Загрузить файл приватного ключа». Публичный ключ Termix вычислит из приватного сам. Если ключ защищён паролем — его вводят в поле «Пароль ключа».

После этого в настройках хоста выбирается способ входа «Учётные данные» и нужный ключ из списка. Один ключ — десять серверов, менять в одном месте.

Как ключи хранятся на самом деле

Здесь важно не обмануться словом «зашифровано». Устроено так: каждое чувствительное поле (пароли, приватные ключи) шифруется персональным ключом пользователя алгоритмом AES-256-GCM, сам этот персональный ключ зашифрован мастер-ключом сервера, а вся база SQLite целиком лежит на диске в зашифрованном виде — файл db.sqlite.encrypted. Мастер-ключ и ключ базы хранятся рядом, в файле .env внутри тома с данными, и генерируются автоматически при первом запуске.

Что ещё умеет Termix

Бэкап и обновление

Все данные Termix — база с хостами и ключами, ключи шифрования, журналы сессий — лежат в одном docker-томе. Бэкапить нужно именно его целиком: без файла .env из этого тома базу расшифровать не получится, а без базы бесполезен сам .env. Сертификат Let's Encrypt в томе не лежит — он в /etc/letsencrypt на сервере, и при переезде проще выпустить его заново.

Контейнер периодически перезаписывает файл базы, поэтому перед копированием его лучше остановить — так вы точно получите целостный снимок:

cd /opt/termix
sudo docker compose stop
sudo docker run --rm -v termix_termix-data:/data:ro -v /root:/backup alpine \
  tar czf /backup/termix-backup.tar.gz -C /data .
sudo docker compose start

Имя тома складывается из имени каталога и имени тома в compose-файле. У нас каталог /opt/termix, поэтому том называется termix_termix-data. Проверить точное имя всегда можно командой sudo docker volume ls.

Восстановление из архива — обратная операция:

cd /opt/termix
sudo docker compose stop
sudo docker run --rm -v termix_termix-data:/data -v /root:/backup:ro alpine \
  sh -c "rm -rf /data/* /data/.env && tar xzf /backup/termix-backup.tar.gz -C /data"
sudo docker compose start

Обновление — две команды. Своих автоматических копий перед каждым обновлением Termix не делает (каталог backups внутри тома появляется только при разовых крупных миграциях базы), так что ваш архив — единственная страховка:

cd /opt/termix
sudo docker compose pull
sudo docker compose up -d

Проект развивается очень быстро, поэтому обновляйтесь регулярно — это ещё и способ вовремя получать исправления безопасности. Если стабильность важнее свежести, вместо :latest в compose-файле можно указать конкретную версию, например ghcr.io/lukegus/termix:2.6.1.

Частые проблемы

sudo nginx -t && sudo systemctl reload nginx