OpenClaw SSH
Практика диагностики переадресации портов

Цель: плоскость управления только через loopback, минимальная поверхность атаки

Шлюз OpenClaw по умолчанию мультиплексирует WebSocket и HTTP на порту 18789. Согласно справочнику конфигурации, gateway.bind: "loopback" ограничивает listener локальным адресом, а для привязки не к loopback требуется включить аутентификацию шлюза (токен, пароль или строго настроенный доверенный прокси). Для общего удалённого Mac оптимальный вариант: loopback + режим токена — администраторы и автоматизированные инструменты обращаются к порту через зашифрованный туннель, не выставляя 18789 на публичный интерфейс хоста.

Дополните эту статью материалом: OpenClaw на узле nozcloud Германия: запуск демона и базовый уровень соответствия. Для покупки или изменения конфигурации перейдите на страницу покупки и сравните тарифы на странице цен.

Минимально воспроизводимые шаги (удалённый Mac)

Рекомендуется сначала выполнить следующий порядок действий на тестовой машине, убедиться в корректности, а затем перенести те же plist, SSH-конфигурацию и CI-задачи в продакшен.

1. Базовая SSH-конфигурация. Создайте отдельного пользователя macOS для OpenClaw. Установите только утверждённую версию OpenClaw, затем проверьте неинтерактивный SSH с аутентификацией по ключу (при допустимой политике — отключите парольную аутентификацию для этого аккаунта в sshd_config).
2. Объявите привязку и аутентификацию в JSON5. В ~/.openclaw/openclaw.json оставьте gateway.mode: "local", задайте gateway.bind: "loopback" и настройте gateway.auth.mode: "token" с gateway.auth.token: "${OPENCLAW_GATEWAY_TOKEN}". Если присутствуют и объект token, и объект password — явно укажите gateway.auth.mode, чтобы избежать неоднозначности при запуске.
3. Внедряйте токен, а не фиксируйте путь к секрету в Git. Экспортируйте OPENCLAW_GATEWAY_TOKEN через словарь EnvironmentVariables LaunchDaemon или через env-файл в собственности root со строгими POSIX-правами. При первоначальной загрузке можно выполнить openclaw doctor --generate-gateway-token в защищённом администраторском Shell.
4. Проверка работоспособности без TTY. Последовательно выполните openclaw config validate и openclaw doctor --non-interactive. Флаг --non-interactive пропускает интерактивные подсказки, применяет безопасные миграции и избегает интерактивного обновления OAuth — идеально для cron и CI.
5. Установите или перезапустите службу шлюза. Используйте стандартизированный вендорский процесс (например, openclaw gateway install с зафиксированными параметрами). Убедитесь, что openclaw gateway status показывает listener здоровым только на loopback-адресе.
6. Установите SSH LocalForward с локальной рабочей станции. Выполните ssh -N -L 18789:127.0.0.1:18789 openclaw-svc@germany-host.example (замените имя пользователя и хост). Локальные инструменты смогут обращаться к ws://127.0.0.1:18789, а трафик будет зашифрован через SSH.
7. Проверьте путь токена. После установки туннеля подключитесь с ноутбука к 127.0.0.1:18789 с Bearer Token согласно операционному руководству. Намеренно отправьте неверный токен — должен вернуться отказ в аутентификации, а не молчаливый пропуск. Это подтверждает сквозное применение ограничений.

Контрольный список для оценки поверхности атаки (compliance)

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

• Никогда не оставляйте токены в открытом виде в истории Shell: загружайте секреты через LaunchDaemon или CI-инжектор, не используйте inline-export в общих экранных сессиях.
• Разделяйте SSH-аккаунты администраторов и служебные аккаунты: каждый человек — отдельный UNIX-субъект; демон-пользователь OpenClaw не должен иметь доступа к вашим личным dotfiles.
• Просматривайте изменения конфигурации шлюза в PR: любые изменения gateway.bind, gateway.auth, hooks или эндпоинтов gateway.http требуют двойного ревью.
• Резервируйте конфигурацию перед запуском doctor: сохраняйте копию openclaw.json с временной меткой до обновления; при потере аутентификационных метаданных после миграции — восстановите из артефактного хранилища и перезапустите службу.
• Документируйте аварийные процедуры: если кто-то временно ослабил режим привязки в ходе реагирования на инцидент — немедленно создайте тикет и откатите изменения в рамках SLA-окна.

Gate-контроль при слиянии (пример псевдокода GitHub Actions)

Зафиксируйте в Git только зафиксированные read-only-конфигурации продакшена или обезличенные выдержки — никогда не фиксируйте продакшен-токены. Внедрите одноразовый OPENCLAW_GATEWAY_TOKEN через секреты CI, чтобы пути валидации, требующие подстановки переменных окружения, работали корректно. Задача должна включать следующие шаги:

1. Установите ту же минорную версию OpenClaw, что и в продакшене.
2. Примените openclaw config validate к объединённому результату зафиксированного шаблона и тестового секрета.
3. Запустите openclaw doctor --non-interactive; завершите с ошибкой, если предупреждений больше, чем задано политикой (многие команды считают любую строку «отсутствует аутентификация» жёсткой ошибкой).
4. Опционально: запускайте openclaw doctor --deep ночью, а не при каждом PR — глубокое сканирование занимает больше времени и может потребовать повышенных привилегий.

Вопросы обновления решайте по внутреннему операционному руководству; при проблемах с выделением ресурсов или SSH-доступом создайте тикет через ссылку на центр помощи ниже.