Безопасен ли OpenClaw 2.0 на VPS? Проверка за 7 дней: права, SSH, API-ключи

Поставить OpenClaw 2.0 на Linux VPS — лёгкая часть. Gateway, который отвечает в чате, и хост, который можно оставить на неделю, — разные вещи. Штатная установка на хост сдержанная: bind на loopback, код pairing для незнакомых DM, группы только по упоминанию. На седьмой день кусает то, что инсталлятор не зажимает: sandbox выключен, инструменты сессий видят весь Gateway, ключи API модели могут лежать в файлах, которые агент умеет читать.

Мы держали одну Ubuntu-коробку семь дней: один оператор, удалённый API, один канал Telegram. Каждый день — одно дело: права, SSH и слушатели, ключи API, браузер, изоляция агентов. Вердикт: внутри одного домена доверия её можно оставить крутиться. Это не граница мультиаренды. Официальная документация говорит это на первом экране. Размер коробки — во вчерашних заметках OpenClaw 2.0 про CPU, RAM и диск; здесь только вопрос, какие двери остались открытыми через неделю.

Короткий ответ: безопасно, но с договором

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

Мы каждый день заново гоняли openclaw security audit. Первый день не был голым портом — установка на хост остаётся на loopback, 18789 не всплывает в публичном скане. Громкими были выполнение инструментов на хосте и видимость сессий на весь Gateway. Оставить это и добавить браузерный навык плюс персону «семья, только чтение» — и радиус взрыва прыгает с «эта VM» на «каждая расшифровка и каждый секрет на этой VM».

Семь дней без зачёта «не случилось инцидента»

Коробка — 2 vCPU / 8 ГБ Ubuntu 24.04, нативный install.sh, удалённый API, пользовательский юнит systemd. SSH только ключами, вход по паролю выключен. Gateway оставался на bind: loopback; Control UI мы открывали локальным SSH-форвардом и ни разу не открывали 18789 в облачной security group. Telegram оставался на pairing. Docker-sandbox мы нарочно не включали, чтобы на седьмой день осталась настоящая поза по умолчанию.

Каждое утро три артефакта: openclaw security audit --json, ss -lntp сверка с файрволом провайдера и обход прав плюс открытых ключей под ~/.openclaw. Мы не ставили оценку «сработала ли prompt injection». Мы ставили оценку дрейфу конфига и файлам, которые агент (или мы) оставили читаемыми всем.

Проверка 1: права — exec по-прежнему падает на хост

Песочница в OpenClaw 2.0 необязательна. Gateway всегда остаётся на хосте; инструменты уходят в Docker или Podman только после agents.defaults.sandbox. Если выключено, host=auto падает на машину gateway. Для личного помощника, которому вы доверяете, это удобно. Для дежурного бота, которому придут ссылки, пересылки и вложения, это проводка prompt injection к оболочке пользователя деплоя.

Аудит первого дня держал две пометки: широкий радиус инструментов и security="full" — документированный дефолт доверенного оператора, не CVE. Наш разрез: личный главный агент может оставить exec на хосте, если pairing включён, файловые инструменты остаются в workspace, а tools.elevated выключен. Второй агент для семьи или публичной комнаты обязан иметь sandbox.mode: "all", workspace ro или none, и отказ в exec, browser, gateway и cron.

Режимы каталогов уплывают быстрее, чем ждут. scp с ноутбука, том Docker или копирование openclaw.json самим агентом превращают 600/700 в 644/755. openclaw security audit --fix подтягивает режимы состояния и конфига. Песочницу он не включает. Гоняйте Gateway от своего пользователя Linux, чтобы ключи, хранилище сессий и workspace жили в его домашнем каталоге, а не у ubuntu или root.

Проверка 2: SSH и bind — плоскость управления вне публичной сети

Второй день — внешний скан. На пути установки на хост 18789 слушал только 127.0.0.1. Security group пускала 22. Сканер Gateway не увидел. Это документированный дефолт обычного хоста и самое спокойное наблюдение недели. Образы контейнеров — другая история: по умолчанию открытый bind, нужна аутентификация. Опубликованные порты Docker — это не «так же безопасно, как установка на хост».

Для SSH мы требовали только три вещи: без входа по паролю, без пароля root, без древних типов ключей. Удалённый доступ к Gateway шёл через SSH-туннель (или Tailscale), не через «reverse-proxy Control UI на 443 и забыть токен». HTTP и WebSocket делят один порт, включая Control UI и виджеты, которые пишет агент. Официальная линия считает эти виджеты недоверенным содержимым. Не кладите их на тот же origin, что уже залогиненная админка.

Опубликованные порты контейнера обходят INPUT хоста и едут по собственной цепочке форварда Docker. Документация по безопасности указывает цепочку DOCKER-USER. Если крутите контейнер, перепроверяйте по публичному IP, а не по ss внутри namespace. Для разреза файрвол против loopback берите матрицу минимальной экспозиции Linux: SSH и HTTPS, затем возвращайтесь сюда и спрашивайте, не перевернул ли кто bind на 0.0.0.0 за неделю.

Pairing узла тоже SSH-поверхность. sshVerify читает личность устройства обратно по операторскому SSH; одной достижимости недостаточно. autoApproveCidrs по умолчанию выключен и покрывает только первый, без scope, роль node. Оба дефолта мы оставили. Удобство — не причина автоматически одобрять вторую машину.

Проверка 3: ключи API — открытый текст на диске агент всё ещё читает

Третий день — обход секретов. В OpenClaw 2.0 есть SecretRef: поля apiKey провайдера, токен Gateway и часть канальных учётных данных могут резолвиться из env, file, exec или store. Открытый текст по-прежнему работает. SecretRef — opt-in на поле. «Мы обновились до 2.0» не значит «ключи ушли с диска».

Риск не в том, что «ключ есть на дежурном хосте». Риск в ключе там, где его откроют read или exec: openclaw.json, .env, сгенерированный agents/*/agent/models.json, архивы отставших auth-profile. Prompt injection не обязана ломать SSH, если модель согласится «прочитать конфиг и вставить в чат». Руководство по секретам OpenClaw считает миграцию законченной только когда поддерживаемые поля стали SecretRef, старый открытый текст вычищен, а openclaw secrets audit --check чистый. Учётные данные без SecretRef по-прежнему нуждаются в пользователе ОС, контейнере или внешнем прокси.

Токен Gateway — отдельный класс. Общий секрет, который может вызвать /v1/chat/completions, /tools/invoke или админский RPC, — полные операторские полномочия. Не кладите его в workspace агента, в репозиторий навыков или «для удобства» второму боту. Ротация короткая: новый токен, перезапуск, обновление клиентов, доказательство, что старое значение умерло. Мы перенесли ключи модели в env SecretRef и оставили токен Gateway в env-файле только для пользователя деплоя. Строк sk- в workspace не осталось.

Проверка 4: браузер — вы отдаёте модели руки оператора

На четвёртый день мы включили браузерный навык и в тот же день выключили. Не потому что Chromium съел RAM — 8 ГБ один проход выдерживают, — а потому что удалённое управление браузером в документации равно доступу оператора. Агент наследует логины, cookie и сохранённые пароли этого профиля. Ваш ежедневный профиль Chrome — не инструмент.

Изоляция слоями: отдельный профиль, менеджер паролей и синхронизация выключены, отдельный каталог загрузок как недоверенный, порты управления только на loopback или tailnet, никогда Funnel. OpenClaw 2.0 умеет гонять sandbox-браузер в своём контейнере на openclaw-sandbox-browser, allowHostControl по умолчанию выключен. SSRF строгий; частные адреса закрыты, пока вы не поставите dangerouslyAllowPrivateNetwork. Мы это оставили выключенным.

Релеи расширений и удалённый CDP — «если видите вкладку, вы этот человек». Режим существующей сессии не безопаснее; он просто больше вы. Узел на десктопной машине после pairing — администратор. Gateway и узел держите в одной частной сети. Правило недели: текстовому помощнику браузер не нужен. Если всё же нужен — профиль без личных аккаунтов и не делите RAM с локальной моделью 7B.

Проверка 5: изоляция агентов — дефолты не арендаторы

На пятый и шестой день мы добавили второго агента только для чтения и решили, что сессии разойдутся. Не разошлись. По умолчанию tools.sessions.visibility — all; tools.agentToAgent.enabled — true. Агент без песочницы может перечислять, искать и читать сессии других, включая персону, которую вы считали «семейной, только чтение». Вызовы из песочницы остаются на своём дереве порождения, но это не прячет их расшифровки от главного агента без песочницы.

Разделение персон на одном Gateway значит видимость agent или self, agent-to-agent выключен или в списке разрешения, и никакого sandbox scope: "shared". Если боту могут писать в DM больше одного человека, поставьте session.dmScope в per-channel-peer, иначе все DM скатываются в главную сессию. Это перила сотрудничества, не стены враждебных арендаторов. Клиенту A и клиенту B нужны два Gateway.

Инструменты плоскости управления режутся так же. gateway читает конфиг (топология и намёки на секреты). cron продолжает после вашего выхода. Любой агент, который увидит недоверенное содержимое, должен отказать обоим, плюс sessions_spawn и sessions_send. Плагины и деревья навыков — доверенный код: закрепляйте источники, используйте plugins.allow, перезапускайте после изменений.

День 7: что уплыло, что нет

Последний круг: bind всё ещё loopback, pairing всё ещё pairing, 18789 в security group никто не открыл. Уплыли отладочная копия .env в workspace и закомментированный allowHostControl после браузерного опыта — чуть не попали в «прод»-файл при слиянии. После --fix режимы файлов были чистыми. Пока sandbox главного агента выключен, аудит по-прежнему клеит позу «доверенный оператор», не «многопользовательская».

Читайте таблицу как решение: OpenClaw 2.0 может стоять неделю или год на VPS, если вы принимаете один Gateway как один домен доверия и заново гоняете аудит перед второй персоной, браузером или публичным reverse-proxy. Новая функция не нужна. Нужно, чтобы история по умолчанию «я доверяю оператору» совпала с реальной угрозой.

Закрыть: список по сценам

Не гонитесь за «корпоративным zero trust» за один присест. Запишите условия, которые все должны быть истинны для нагрузки сегодняшней ночи. Если они бьются — делите машины. Лишние исключения в одном конфиге дороже второй коробки.

Две операционные мелочи — мелочи безопасности: токены в логах и плагины из источника, который вы не читали. Включите маскирование и ротацию; закрепите plugins.allow. Потом решите, должна ли Linux-дежурка дальше держать операторские ключи — или этим ключам место на более тихой плоскости управления.

FAQ

Только текст, заводские дефолты — увидит ли публичный скан Gateway?

Установка на хост с loopback не покажет 18789 в публичном интернете. Сначала закройте pairing. Незнакомец, который уже может написать вам в DM, — настоящий первый прыжок, не nmap.

Docker сам по себе безопаснее?

Образы помогают откату и изоляции файловой системы. Официальные контейнеры по умолчанию с открытым bind, опубликованные порты обходят INPUT хоста. Без auth и внешней перепроверки Docker обычно опаснее, не безопаснее.

Заменяет ли audit --fix ручные правки?

Нет. Он возвращает открытые групповые политики к спискам разрешения и чинит режимы 600/700. Он не включает песочницу, не мигрирует SecretRef и не сужает видимость сессий.

Может ли модель сама прочитать ключ API?

Если открытый текст лежит на пути, который агент умеет читать, файловые инструменты или exec его откроют. SecretRef уменьшает остаток на диске. Это не изоляция процессов. Не сочетайте недоверенное содержимое с exec на хосте.