OpenClaw 24/7 на VPS: сигурна инсталация

На лаптопа OpenClaw замлъква в момента, в който затворите капака: съобщенията в WhatsApp се трупат, планираните задачи чакат да се върнете. На сървър той продължава да отговаря. Уловката е, че шлюзът не е чат джаджа. Той пази данните за достъп до каналите ви и, ако не включите sandbox, изпълнява инструменти направо на хоста. Преместването му на винаги включена машина си струва само ако моделът на сигурност се мести заедно с него.

Това ръководство го прави за около 20 минути на нов VPS с Ubuntu 24.04.

Последна проверка на 2026-10-04 с OpenClaw 2026.9.8 (npm), Node 24.21 LTS и Ubuntu 24.04.

Какво ви трябва

• Linux VPS. Ние ползваме нашия план AI-Agent: 4 vCPU, 4 GB RAM, 40 GB диск, $10 на месец. Документацията на OpenClaw споменава 6 GB RAM, но това е за изграждане на техния Docker образ от изходен код; npm пакетът не изисква компилиране.
• API ключ от доставчика на модели и чат акаунтите, които искате да свържете.
• SSH ключ на лаптопа. Ако още нямате: вход със SSH ключ.

NAT план тук върши отлична работа, а може би дори пасва по-добре. Шлюзът никога не се нуждае от отворен входящ порт: WhatsApp, Discord и Telegram (по подразбиране long polling) се свързват навън, а до панела стигате през SSH. Вземете собствен IPv4 само ако нужен ви канал доставя чрез webhook или планирате публичен reverse proxy.

1. Потребител, който не е root

OpenClaw изпълнява инструменти като потребителя, който притежава шлюза. Ако това е root, като root ще се изпълни и всяка команда, която объркан или подведен чрез prompt injection модел реши да пусне. Документацията на OpenClaw нарича пускането на шлюза като root опасно и неподдържано. Създайте отделен потребител без sudo:

# като root
apt update && apt -y upgrade
adduser --disabled-password --gecos "" claw
install -d -m 700 -o claw -g claw /home/claw/.ssh
install -m 600 -o claw -g claw ~/.ssh/authorized_keys /home/claw/.ssh/authorized_keys   # ключът, добавен при поръчката
loginctl enable-linger claw

Последният ред е по-важен, отколкото изглежда. OpenClaw инсталира потребителска systemd услуга и без lingering тя спира, когато излезете. Това е най-честото „вчера работеше“ на сървъри.

2. Node 24 и OpenClaw

OpenClaw 2026.9.8 изисква Node >=24.16.0 <25 или >=26.1.0. Пакетът nodejs от Ubuntu е по-стар, затова взимаме 24 LTS от NodeSource:

# като root
curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
node -v          # v24.16.0 или по-нова
npm install -g openclaw@latest
openclaw --version

Официалната команда на един ред (curl -fsSL https://openclaw.ai/install.sh | bash) също работи и сама инсталира Node. На сървър предпочитаме двете явни стъпки: виждате кое къде отива, а изпълнимият файл е в /usr/bin, а не в домашна директория, в която агентът може да пише.

3. Onboarding като потребителя на агента

Влезте като claw по SSH, а не чрез su. Само истински вход стартира потребителския мениджър на systemd, от който услугата има нужда:

# от лаптопа (NAT план: добавете -p <вашия SSH порт>)
ssh claw@<server>

openclaw onboard --install-daemon
openclaw gateway status

Съветникът проверява достъпа до модела, записва ~/.openclaw/openclaw.json, генерира токен на шлюза и инсталира услугата. Ако systemctl --user се оплаква от шината, задайте export XDG_RUNTIME_DIR=/run/user/$(id -u) и опитайте пак.

После заключете файловете. Препоръката на самия OpenClaw е 700 за директорията със състоянието и 600 за конфигурацията:

chmod 700 ~/.openclaw && chmod 600 ~/.openclaw/openclaw.json
openclaw security audit --deep

openclaw security audit --fix прилага безопасната част от поправките: по-строги права на файловете и списъци с разрешени вместо отворени групови политики. Не сменя адреса, на който слуша, и не настройва защитна стена; мрежовата изложеност остава ваша грижа.

4. Дръжте шлюза на loopback

Шлюзът сервира своето WebSocket API и панела на един порт, 18789, обвързан по подразбиране с 127.0.0.1. Оставете го така. Минимална конфигурация, която го записва изрично:

// ~/.openclaw/openclaw.json
{
  gateway: {
    mode: "local",
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "paste-output-of-openssl-rand-hex-32" },
  },
}

Генерирайте токена с openssl rand -hex 32 или openclaw doctor --generate-gateway-token. Шлюзът отказва празни токени и примерните стойности, а одитът предупреждава под 24 символа.

Какво да не правите: да сменяте bind на "lan" и да отваряте порта. Документацията е категорична: никога не излагайте шлюза без удостоверяване на 0.0.0.0 и не пренасочвайте порта широко дори с токен. Който получи този токен, става оператор на процес, който изпълнява команди на сървъра ви.

На защитната стена разрешете SSH и нищо друго:

# като root
ufw allow OpenSSH
ufw enable
ufw status verbose

При нашите NAT планове таблото показва външен SSH порт, но вътре в сървъра sshd продължава да слуша на 22. Разрешете OpenSSH (порт 22), а не номера на външния порт, иначе ufw enable ще ви заключи отвън. Повече в ръководството за UFW.

5. До панела през SSH

От лаптопа отворете тунел и го оставете да работи:

ssh -N -L 18789:127.0.0.1:18789 claw@<server>
# NAT план: ssh -N -p <вашия SSH порт> -L 18789:127.0.0.1:18789 claw@<host>

Отворете http://127.0.0.1:18789/ и поставете токена на шлюза. Стандартният sshd в Ubuntu позволява локално пренасочване; ако сте го затегнали, AllowTcpForwarding local е настройката, която позволява -L и блокира отдалечените пренасочвания. Ако тунелът пада с administratively prohibited, проверете точно този ред.

Tailnet също върши работа: Tailscale Serve държи шлюза на loopback и управлява достъпа. И двата варианта са наред. Публичен порт не е.

6. Сдвояване, sandbox и кой може да говори с него

Чат каналите са вторият вход. По подразбиране каналите с лични съобщения карат непознатите податели да се сдвоят първо; вие одобрявате от сървъра:

openclaw pairing approve <channel> <code>

В групите изисквайте споменаване, за да не отговаря агентът на всяко съобщение в стаята. Затегнатата базова конфигурация на OpenClaw ползва dmPolicy: "pairing" и groups: { "*": { requireMention: true } } за всеки канал.

Две честни уговорки. Първо: сдвояването решава кой може да стартира ход, а не какво ще влезе в контекста на модела; препратено съобщение или изтеглена уеб страница пак могат да насочат ход, стартиран от вас. Второ: инструментите на основната сесия работят на хоста, докато не включите sandbox (agents.defaults.sandbox.mode: "non-main" изолира всичко освен собствената ви основна сесия). Sandbox е изключен по подразбиране, а стандартният му бекенд е Docker, така че инсталирайте Docker, преди да го включите: Docker на VPS. Ако хора, на които не вярвате, споделят канал с бота, ползвайте отделен шлюз, най-добре на отделен сървър.

7. Обновления и резервни копия

openclaw update
openclaw gateway status
openclaw backup create --output ~/backups/openclaw --verify

В ~/.openclaw са конфигурацията, данните за достъп до каналите (включително сесията на WhatsApp), профилите за удостоверяване на моделите и записите на сесиите. Загубите ли го — сдвоявате всичко наново; изтече ли — някой друг става вас в WhatsApp. Правете копия и ги пазете извън сървъра: изтеглете ги със scp или ползвайте restic с криптиране.

Контролен списък

Къде е мястото на EQVPS

Мнозина могат да пуснат Node процес. Ние добавяме плащане с крипто без KYC, NAT план, който пасва на шлюз само на loopback, и MCP сървър, чрез който агентът ви може сам да управлява своите сървъри. Ако свързвате OpenClaw с него, първо прочетете предпазителите за MCP: токен, с който могат да се поръчват сървъри, заслужава същата грижа като токена на шлюза. За по-широк поглед върху агентите на VPS вижте ръководството за AI агенти.

Нашето мнение: тези 20 минути са разликата между асистент и отворен shell с чат интерфейс. Дори да пропуснете останалото, направете стъпки 1, 4 и 5.