Если Web UI открывается на удалённом Mac, но вы не понимаете, кому он реально доступен, не публикуйте порт сразу: для личного доступа оставьте loopback и используйте SSH-туннель, а публичный вход выбирайте только вместе с отдельной аутентификацией, TLS, журналированием и ограничением источников.

План на эту неделю: сначала проверьте фактическое состояние 127.0.0.1 и 0.0.0.0, затем проведите тест через внешнее устройство. Если доступ нужен одному разработчику или небольшой фиксированной группе, остановитесь на SSH-туннеле. Если Web UI должен стать постоянным командным входом, проектируйте обратный прокси как отдельный контур безопасности, а не как простой проброс порта.

Эта статья предназначена для трёх групп:

  • Личным разработчикам, которым нужно время от времени открыть интерфейс с другого компьютера.
  • Платформенным инженерам, которым требуется стабильный вход для нескольких участников.
  • Ответственным за безопасность, проверяющим, связаны ли сетевой доступ, доверие к Host, аутентификация и права Harness в единую цепочку контроля.

Официальный запуск Web UI выполняется командой npx @deepseek-ai/dsh web. В актуальном README по умолчанию указан адрес http://127.0.0.1:3080, а сам проект находится в режиме developer preview и может получать обратно несовместимые изменения. Перед внедрением сверяйте официальное описание запуска Web UI и руководство по Web UI.

01

Уровень входа по числу пользователей

Выбор начинается не с команды запуска, а с масштаба доступа. Сетевой адрес отвечает на вопрос «откуда можно установить TCP-соединение». Он не отвечает на вопрос «кто получил право пользоваться рабочей областью».

Сценарий Предпочтительный вход Сетевой охват Что обязательно проверить
Один пользователь, редкий доступ Loopback + SSH-туннель Только удалённый порт через SSH Ключ SSH, закрытие туннеля, отсутствие внешнего порта
Небольшая фиксированная группа Контролируемый прокси или VPN-подобный контур Ограниченный список сетей или пользователей Отдельная аутентификация, TLS, отзыв доступа, журнал входов
Постоянная команда HTTPS-вход через обратный прокси Только заявленные источники Идентификация пользователя, сессии, аудит, аварийное отключение, владелец изменений

Для личного удалённого доступа сохранение loopback — не формальность. При 127.0.0.1 Web UI продолжает слушать локальный интерфейс, а SSH временно переносит доступ к нему на ваш клиент. Внешний пользователь не получает прямой маршрут к приложению.

При прослушивании на 0.0.0.0 процесс принимает соединения на всех доступных IPv4-интерфейсах. Это расширяет поверхность сети, но не создаёт логин, сессию или проверку полномочий. Внутри Web UI всё равно остаются отдельные вопросы: выбранная рабочая область, разрешения на операции, API-ключ и доступ к файлам. После запуска нужно отдельно выбрать workspace, а операции с запросом подтверждения зависят от активной политики разрешений.

Сценарий: удалённый Mac для одного разработчика

Допустим, DeepSeek Harness запущен на удалённом Mac, а вы работаете с ноутбука в другой сети. Вам нужен интерфейс несколько раз в день, но другим сотрудникам доступ не требуется.

В таком случае публичный вход создаёт лишние обязанности:

  • нужно поддерживать сертификат и правила прокси;
  • нужно понимать, как отзывать доступ конкретного пользователя;
  • нужно собирать логи отказов и успешных сессий;
  • нужно повторно проверять маршрут после обновления Harness;
  • нужно контролировать, не стал ли порт видимым после перезапуска.

SSH-туннель решает только задачу транспортировки соединения. Это его преимущество и одновременно предел. Он не является заменой командной модели доступа.

02

Сетевой охват и фактическая доступность

Разница между SSH-туннелем и публичным входом лучше всего видна по четырём проверкам:

  1. На каком адресе действительно слушает процесс.
  2. Доступен ли порт с другого устройства.
  3. Какие значения Host принимает приложение.
  4. Можно ли закрыть вход без остановки всей рабочей среды.

Для проверки на Mac используйте команды, согласованные с вашей системой:

lsof -nP -iTCP:3080 -sTCP:LISTEN

Если в результате указан 127.0.0.1:3080, процесс слушает loopback. Если указан *:3080, 0.0.0.0:3080 или конкретный внешний адрес, доступность шире. Команда запуска и порт должны быть перепроверены по текущей версии, потому что developer preview может быстро меняться.

На внешнем устройстве проверяйте не только открытие страницы:

nc -vz <адрес-удалённого-Mac> 3080

Отрицательный результат при loopback — ожидаем. Положительный результат при 0.0.0.0 означает лишь сетевую доступность. Он не подтверждает аутентификацию.

Для SSH-туннеля используется локальный порт клиента и локальный адрес удалённого сервера:

ssh -N -L 3080:127.0.0.1:3080 user@remote-host

После установки соединения откройте на своём компьютере:

http://127.0.0.1:3080

Ключевой момент — второй адрес 127.0.0.1. Он относится к удалённому Mac, где работает Harness, а не к вашему ноутбуку. Опция -L создаёт локальное перенаправление через зашифрованное SSH-соединение. Подробное поведение локального port forwarding описано в официальной документации OpenSSH.

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

При публичном входе необходимо заранее определить:

  • точное имя или адрес внешнего входа;
  • разрешённые сети, IP-адреса или группы;
  • способ закрытия доступа;
  • кто отвечает за сертификат;
  • где сохраняются логи;
  • как отключается конкретная учётная запись.

Без этих параметров 0.0.0.0 превращается не в архитектуру, а в неопределённое расширение зоны риска. В документации OpenSSH отдельно отмечено, что пустой адрес или * могут сделать порт доступным на всех интерфейсах, тогда как localhost ограничивает привязку локальным использованием. Это полезная проверка и для самого SSH-клиента: описание bind address и port forwarding.

03

trustedHosts и пользовательская аутентификация

trustedHosts нельзя использовать как замену логину. Эта настройка относится к доверию к authority из HTTP-запроса — прежде всего к значению Host и связанным с ним адресным сценариям. Она помогает ограничить, какие имена хоста приложение считает допустимыми. Она не доказывает, что запрос отправил именно нужный сотрудник.

Стандарт HTTP описывает Host как сведения о хосте и порте целевого URI, позволяющие серверу различать ресурсы при работе с несколькими именами. Поэтому проверка Host относится к маршрутизации и допустимому имени входа, а не к личности пользователя. Подробное определение находится в RFC 9110 о семантике HTTP.

Это различие удобно проверять по слоям:

Слой контроля На какой вопрос отвечает Пример проверки Чего он не делает
Сетевой маршрут Может ли клиент добраться до порта nc, firewall, security group Не определяет пользователя
trustedHosts Допустим ли Host authority Запрос с разрешённым и запрещённым Host Не выдаёт учётную запись
Аутентификация Кто отправил запрос SSO, одноразовый код, клиентский сертификат или другой подтверждённый механизм Не ограничивает сам сетевой маршрут
Права Harness Что пользователь может делать Workspace, разрешения инструментов, подтверждение опасных операций Не защищает внешний порт без входного контроля

Поэтому ситуация «trustedHosts настроен, но входа нет» является нормальной. Настройка доверенного Host может отклонить запрос с неподходящим именем, но она не обязана показывать форму логина или создавать пользовательскую сессию.

При проверке значения trustedHosts проведите два отдельных теста:

  1. Отправьте запрос с ожидаемым Host.
  2. Повторите запрос с заведомо чужим Host и проверьте отказ.

Затем отдельно проверьте вход пользователя:

  1. Откройте страницу без действующей сессии.
  2. Убедитесь, что защищённые действия недоступны.
  3. Войдите разрешённым способом.
  4. Отзовите доступ и повторите запрос.
  5. Убедитесь, что старая сессия не продолжает выполнять операции.

Если второй набор проверок отсутствует, trustedHosts нельзя называть аутентификацией. Это только один из барьеров на уровне HTTP authority.

04

Шифрование, TLS и границы секретов

SSH-туннель и HTTPS-вход решают разные задачи.

SSH-туннель обычно оставляет Web UI на loopback и защищает канал между вашим клиентом и удалённым Mac. У вас появляется одна точка идентификации — SSH. Если доступ нужен нескольким людям, каждому нужны отдельные ключи, отдельные правила отзыва и понятный журнал операций.

HTTPS через обратный прокси переносит ответственность на входной слой. Он должен:

  • завершать TLS;
  • проверять пользователя;
  • передавать запрос к Web UI по контролируемому внутреннему маршруту;
  • сохранять исходные данные для аудита только в безопасном объёме;
  • не доверять произвольным X-Forwarded-* заголовкам;
  • иметь понятную кнопку или команду аварийного закрытия.

TLS защищает транспорт, но не заменяет идентификацию. Сертификат подтверждает защищённый канал и имя сервиса, а не право конкретного человека запускать операции в workspace. Спецификация TLS 1.3 описывает защиту от прослушивания, изменения данных и подделки сообщений, но не задаёт прикладную модель ролей Web UI. Сверяйте транспортные требования с официальной спецификацией TLS 1.3.

Секреты нужно проверять отдельно. В руководстве Web UI указано, что API-ключ вводится в разделе настройки моделей и становится доступным без перезапуска сервера. Это означает, что вы должны проверить, где ключ хранится после сохранения, кто имеет доступ к профилю пользователя и не попадает ли он в журналы браузера, прокси или снимки окружения.

Для публичного входа используйте минимальный набор:

  • API-ключ не помещается в URL;
  • ключ не передаётся через общий чат или общую учётную запись;
  • прокси не пишет секретные заголовки в обычный access log;
  • браузерный канал работает только через HTTPS;
  • тестовая учётная запись не имеет доступа к рабочим каталогам, которые ей не нужны;
  • после отзыва сессии прежний браузерный токен перестаёт работать.

Публичная страница без независимой аутентификации — неприемлемый вариант даже при корректном TLS. Это особенно важно для Harness, поскольку Web UI может работать с файлами, командами, планами и действиями, требующими подтверждения.

05

Аудит и стоимость сопровождения

Главный недостаток SSH-туннеля для команды — не шифрование. С шифрованием у него как раз всё понятно. Сложность возникает в управлении участниками.

Для одного пользователя достаточно знать:

  • какой ключ используется;
  • на каком хосте работает Harness;
  • как закрыть процесс ssh;
  • как восстановить туннель после обрыва.

Для команды появляются дополнительные вопросы:

  • кто имеет доступ к удалённому Mac;
  • можно ли отозвать одного участника без смены общего секрета;
  • кто видел конкретную сессию;
  • какой workspace использовался;
  • кто изменил прокси или правила источников;
  • как отличить отказ сети от отказа аутентификации;
  • кто проверит конфигурацию после обновления.

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

Официальный репозиторий отдельно предупреждает, что DeepSeek Harness находится в developer preview и допускает несовместимые изменения. Поэтому после обновления проверяйте не только запуск команды, но и:

  • адрес слушателя;
  • реакцию на запрещённый Host;
  • поведение аутентификации;
  • выбор workspace;
  • запросы на подтверждение;
  • восстановление после разрыва.

Историю версий и актуальные теги можно сверять в официальном списке релизов. На 19 августа 2026 года там опубликован тег dsh-v0.1.0-rc.7 от 17 августа 2026 года, но сам факт нового тега не является гарантией сохранения ваших параметров входа.

06

Пошаговая приёмка удалённого Web UI

Используйте эту последовательность перед тем, как передавать ссылку другому человеку.

1. Зафиксируйте исходное состояние

Сохраните:

  • версию Harness;
  • команду запуска;
  • рабочий каталог;
  • порт;
  • фактический адрес слушателя;
  • способ хранения API-ключа;
  • активную политику разрешений.

Не заменяйте эти данные предположением из старой инструкции.

2. Проверьте loopback

На удалённом Mac выполните:

lsof -nP -iTCP:3080 -sTCP:LISTEN
curl -I http://127.0.0.1:3080

Сохраните результат. Если curl работает локально, но внешний клиент не подключается, это ожидаемая модель для SSH-туннеля.

3. Проверьте внешний маршрут

С другого устройства выполните проверку TCP-порта. Если порт не должен быть публичным, отрицательный результат — необходимое условие. Если вы строите командный вход, проверьте доступ только из разрешённой сети и повторите попытку из запрещённой.

4. Проверьте Host authority

Отправьте запрос через ожидаемое имя входа, затем повторите его с неизвестным Host. Запишите код ответа и наличие или отсутствие страницы. Не делайте вывод об аутентификации по одному только отказу Host.

5. Проверьте пользовательскую сессию

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

6. Проверьте рабочую область

Откройте только тестовый проект. Попробуйте чтение, изменение файла и действие, требующее подтверждения. Свежий Web UI не имеет выбранного workspace до отдельного действия пользователя. Используйте это как контрольную точку, а не как средство аутентификации.

7. Проверьте обрыв

Закройте SSH-сессию или временно разорвите сетевой маршрут. Затем восстановите соединение. Для личного доступа должно быть понятно, как снова выполнить ssh -N -L. Для командного входа проверьте, что прокси не оставляет зависшую сессию и что журнал показывает разрыв и повторное подключение.

8. Проверьте аварийное закрытие

Остановите публичный прокси или заблокируйте входящий порт. После этого убедитесь, что локальный Harness не обязан удаляться или менять рабочую конфигурацию. Хорошая схема позволяет закрыть внешний вход, сохранив возможность локальной диагностики.

Финальное решение можно принять по трём условиям:

  • Оставляйте SSH-туннель, если пользователей мало, доступ нерегулярный, а внешний порт не нужен.
  • Стройте контролируемый публичный вход, если есть владелец сервиса, независимая аутентификация, TLS, аудит, список разрешённых источников и процедура отзыва.
  • Возвращайтесь к loopback без удалённого доступа, если вы не можете доказать хотя бы один из перечисленных контролей.

Опыт эксплуатации. Если вам требуется только открыть Web UI с ноутбука, публичный адрес почти всегда создаёт больше точек отказа, чем полезных функций. Сначала измерьте реальную потребность в совместном доступе, а не проектируйте вход «на будущее».

07

Итоговый выбор для команды и удалённого Mac

Для временной работы на удалённом Mac SSH-туннель обычно лучше: сервис остаётся на loopback, маршрут включается только на время сессии, а внешний порт не становится самостоятельной точкой атаки.

Публичный вход оправдан, когда Web UI уже стал командным сервисом. Тогда вам нужны не только trustedHosts и слушатель на не-loopback-адресе, но и независимая аутентификация, TLS, журналы, отзыв пользователей, ограничение источников и ответственный за изменения.

Если ваш текущий вариант — прямой 0.0.0.0 без подтверждённого входа, его недостатки конкретны: любой доступный маршрут видит порт, доверие к Host ошибочно принимается за логин, а отключение отдельного пользователя может оказаться невозможным. Если используется один общий SSH-ключ, аудит действий участников также становится слабым.

Для личных экспериментов разумнее арендовать удалённый Mac с заранее понятным способом подключения и провести приёмку по этой схеме, чем самостоятельно поддерживать публичный порт на рабочей машине. Перед решением можно посмотреть варианты аренды Mac mini, а затем сверить оформление заказа на Mac mini. Если вам нужен долгоживущий стенд, сначала определите, будет ли это временный SSH-доступ или постоянный командный вход: от этого зависят правила сети, аудит и стоимость сопровождения.