Jak bezpiecznie uruchomić OpenClaw na VPS

Czym jest OpenClaw i dlaczego należy go najpierw utwardzić

OpenClaw to agent AI typu self-hosted. Uruchamia się go na własnym serwerze, łączy z dużym modelem językowym, a agent może wykonywać polecenia shell, kontrolować przeglądarkę, odczytywać i zapisywać pliki oraz działać na podstawie wiadomości przesyłanych z aplikacji czatowych. Ten zakres możliwości jest głównym celem tego narzędzia, ale stanowi również główne ryzyko. Agent zdolny do wykonywania dowolnego polecenia jest tak bezpieczny, jak system, na którym pracuje, oraz jak ograniczenia, jakie zostaną na niego nałożone.

Dwa fakty wyznaczają ramy tego przewodnika. Po pierwsze, OpenClaw został zaprojektowany tak, aby użytkownik dokonał jego utwardzenia (hardening). Model bezpieczeństwa przenosi odpowiedzialność za restrykcyjne polityki narzędzi, piaskownicę (sandboxing) oraz ostrożne uprawnienia na operatora, a nie na bezpieczne ustawienia domyślne. Po drugie, projekt miał już poważny incydent bezpieczeństwa: w marcu 2026 roku w ciągu czterech dni ujawniono dziewięć problemów bezpieczeństwa, w tym krytyczną lukę eskalacji uprawnień, CVE-2026-32922, o ocenie 9.9 na 10. Żaden z tych faktów nie oznacza, że należy unikać OpenClaw. Oznacza to jedynie, że nie należy uruchamiać go w sposób niedbały, a niniejszy przewodnik przedstawia bezpieczną metodę postępowania.

Istnieją również dobre wiadomości. OpenClaw zapewnia już jedno bezpieczne rozwiązanie: jego gateway, czyli pojedynczy proces kontrolujący wszystko, domyślnie nasłuchuje na adresie loopback, więc nie jest dostępny z internetu, chyba że zostanie celowo wystawiony na zewnątrz. Większość poniższych działań polega na utrzymaniu tego stanu oraz ograniczeniu zasięgu ewentualnej awarii.

Przypisanie OpenClaw własnego nieuprzywilejowanego użytkownika

Nigdy nie należy uruchamiać agenta jako root. Jeśli OpenClaw działa jako root i wystąpi jakikolwiek błąd — czy to błąd w kodzie, błędna instrukcja, czy luka CVE, jak ta powyżej — skala szkód nie ma limitów. Należy utworzyć dedykowanego użytkownika systemowego bez powłoki logowania (login shell) i bez uprawnień sudo, a następnie uruchomić agenta jako ten użytkownik:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

Wszystko, co należy do OpenClaw, znajduje się pod /opt/openclaw i jest własnością tego konta. Jest to najważniejszy krok, realizujący tę samą zasadę, która została omówiona w uruchamianiu usług jako nieuprzywilejowany użytkownik: konto, z którego działa agent, stanowi limit tego, co może on uszkodzić.

Instalacja OpenClaw

OpenClaw jest dystrybuowany jako pakiet npm, więc jeśli serwer nie posiada Node.js, należy go najpierw zainstalować. Zainstaluj pakiet globalnie, co umieści binarię openclaw w zmiennej PATH dla każdego użytkownika, a następnie wykonaj jednorazowy krok konfiguracji (onboarding):

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

Uruchomienie konfiguracji jako użytkownik openclaw oznacza, że pliki konfiguracyjne agenta trafią do jego katalogu domowego /opt/openclaw, a nie do katalogu root. Projekt oferuje również instalator curl -fsSL https://openclaw.ai/install.sh | bash, który wykonuje tę samą instalację w jednej linii. Podczas konfiguracji pomiń flagę --install-daemon: zarejestrowałaby ona własną usługę OpenClaw, podczas gdy budowana poniżej utwardzona jednostka systemd jest bardziej restrykcyjna.

Utrzymanie gatewaya na loopback, za firewallem

Gateway domyślnie wiąże się z 127.0.0.1. Pozostaw go w tym miejscu. Publikowanie tego portu w internecie jest niemal nigdy uzasadnione, a czyniąc to, dajesz każdemu, kto go znajdzie, zdalny punkt wejścia do procesu wykonującego polecenia.

Przed serwerem należy ustawić firewall typu default-deny, aby nic nie zostało przypadkowo wystawione na zewnątrz:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Należy unikać dwóch pułapek. Firewall obsługujący tylko IPv4 może pozostawić tę samą usługę całkowicie otwartą na IPv6, co stanowi lukę w firewallu IPv6, która dotyka wielu użytkowników. Jeśli konieczne jest połączenie się z gatewayem z laptopa, nie otwieraj portu. Połącz się przez VPN lub tunel SSH, aby agent nigdy nie nasłuchiwał w otwartym internecie.

Izolacja sekretów

OpenClaw wymaga klucza API dla dowolnego podłączonego modelu językowego. Klucz ten może generować koszty i — poprzez agenta — działać w Twoim imieniu, dlatego należy traktować go jak hasło. Nie umieszczaj go w pliku jednostki (unit file) ani w żadnym repozytorium. Umieść go w pliku, do którego dostęp ma wyłącznie użytkownik OpenClaw:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

Jednostka systemd ładuje ten plik za pomocą EnvironmentFile, dzięki czemu klucz trafia do procesu bez przebywania w linii poleceń, logach czy historii powłoki.

Uruchomienie jako utwardzona usługa systemd

Uruchomienie agenta w systemd zapewnia automatyczne restarty, czyste logi poprzez journalctl oraz, co najważniejsze, zestaw opcji piaskownicy na poziomie jądra, które ograniczają zasoby, do których proces może uzyskać dostęp nawet po przejęciu. Najważniejsze dla agenta są: NoNewPrivileges, aby nigdy nie mógł uzyskać nowych uprawnień; ProtectSystem=strict, aby system plików był tylko do odczytu (z wyjątkiem miejsc z uprawnieniami do zapisu); PrivateTmp dla własnego, odizolowanego katalogu tymczasowego oraz ProtectHome, aby nie mógł czytać katalogów domowych użytkowników.

Wygeneruj pełną, utwardzoną jednostkę tutaj, a następnie skopiuj ją do /etc/systemd/system/openclaw.service:

Jednostka uruchamia openclaw gateway, czyli długotrwały proces kontrolujący agenta; jeśli which openclaw wskazuje na serwerze inną ścieżkę, należy dostosować ExecStart. Pełny opis tych dyrektyw oraz daemon-reload i enable --now znajduje się w uruchamianiu programu jako usługa systemd. Krótka wersja po wklejeniu jednostki:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

Utwardzenie również wejścia zewnętrznego

Bezpieczeństwo serwera z agentem zależy od bezpieczeństwa całego systemu. Dwie dodatkowe warstwy kończą proces zabezpieczania. Należy przełączyć SSH na uwierzytelnianie wyłącznie kluczami i wyłączyć logowanie jako root, tak jak w utwardzaniu SSH na VPS, aby konto używane do administracji nie było podatne na ataki brute-force. Następnie należy dodać Fail2ban, aby blokować skanery atakujące każdy publiczny port. Żadna z tych metod nie dotyczy bezpośrednio OpenClaw, ale obie odcinają drogi, których użyłby atakujący, aby do niego dotrzeć.

Regularne aktualizacje

Ujawnienie luk w marcu 2026 roku jest najsilniejszym argumentem za pozostawaniem przy aktualnych wersjach. Błąd eskalacji uprawnień w agencie jest znacznie poważniejszy niż w zwykłej aplikacji webowej, ponieważ agent już wykonuje polecenia. Należy śledzić wydania projektu, szybko instalować aktualizacje bezpieczeństwa i traktować aktualizację OpenClaw jako rutynową konserwację, a nie czynność, którą można odłożyć na później.

Aby zrozumieć, co dokładnie jest utwardzane, zapoznaj się z architekturą agenta typu OpenClaw, a budowaniem własnego agenta AI na VPS opisuje ogólny schemat działania każdego agenta.

FAQ

Czy bezpieczne jest uruchamianie OpenClaw na publicznym VPS?

Może być, jeśli zostanie utwardzony. OpenClaw jest potężny z założenia: wykonuje polecenia shell i kontroluje przeglądarkę, więc niedbała konfiguracja jest faktycznie niebezpieczna (projekt miał już krytyczną lukę CVE-2026-32922 w marcu 2026). Model bezpieczeństwa zakłada, że to operator dodaje ograniczenia. Należy uruchamiać go jako nieuprzywilejowany użytkownik, trzymać gateway na loopbackie za firewallem typu default-deny, odizolować klucze API i uruchomić jako utwardzoną usługę systemd.

Czy należy wystawiać gateway OpenClaw do internetu?

Nie. Gateway domyślnie wiąże się z loopbackiem i należy go tam pozostawić. Jest to pojedynczy proces kontrolujący agenta, więc wystawiony gateway stanowi zdalną drogę do procesu wykonującego polecenia. Jeśli wymagany jest dostęp zdalny, należy użyć VPN lub tunelu SSH zamiast otwierania portu.

Jako użytkownik należy uruchomić OpenClaw?

Jako dedykowany użytkownik systemowy bez powłoki logowania i bez uprawnień sudo, nigdy jako root. Jeśli agent zostanie przejęty, konto użytkownika określa limit szkód, dlatego konto to powinno posiadać własność wyłącznie nad własnymi plikami w katalogu takim jak /opt/openclaw i niczym więcej.

Jak dbać o bezpieczeństwo kluczy API OpenClaw?

Należy przechowywać je w pliku dostępnym tylko dla użytkownika OpenClaw (tryb 600) i ładować do usługi za pomocą funkcji EnvironmentFile systemu systemd. Klucz nie może znajdować się w pliku jednostki, w historii powłoki ani w żadnym repozytorium git. Należy go rotować w przypadku podejrzenia wycieku.