DeepSeek Harness na VPS: bezpieczna instalacja i tunel SSH

Czym jest DeepSeek Harness

DeepSeek Harness (dsh) to środowisko uruchomieniowe agenta oparte na Node.js, które można uruchomić na serwerze VPS (virtual private server). Bezpieczną metodą jego eksploatacji jest powiązanie z 127.0.0.1 i uzyskiwanie dostępu przez przeglądarkę za pośrednictwem tunelu SSH (secure shell). Narzędzie udostępnia interfejs webowy (web UI) na porcie 3080, zamiast działać w terminalu. Serwer ten nie posiada własnego mechanizmu uwierzytelniania hasłem, dlatego wystawienie portu 3080 na świat pozwala każdemu na przejęcie kontroli nad agentem, który może odczytywać pliki i wykonywać polecenia z uprawnieniami użytkownika Linux.

Firma DeepSeek udostępniła narzędzie 13 sierpnia 2026 roku na licencji MIT jako pakiet npm @deepseek-ai/dsh. Projekt jest określany jako wersja poglądowa dla programistów (developer preview), w której należy spodziewać się zmian naruszających kompatybilność. Wszystkie numery wersji poniżej odnoszą się do stanu z sierpnia 2026 roku, dlatego przed instalacją na środowisku produkcyjnym należy sprawdzić aktualny stan repozytorium.

Cała architektura opiera się na jednej koncepcji: wszystko jest wtyczką. Adapter modelu, rejestr narzędzi, dziennik sesji, piaskownica (sandbox), harmonogram oraz pętla agenta to wtyczki ładowane do wspólnego kontekstu, z których każdą można wymienić. Nie istnieje uprzywilejowane jądro, które byłoby jedynie uzupełniane przez wtyczki. To właśnie czyni Harness rozwiązaniem wartym przetestowania, ale jednocześnie stanowi źródło jedynego realnego zagrożenia.

Harness nie jest modelem

Harness uruchamia pętlę agenta. Proces wnioskowania odbywa się w modelu znajdującym się w innym miejscu, dlatego nic nie zadziała, dopóki nie zostanie podany klucz API (application programming interface) lub adres punktu końcowego modelu hostowanego we własnym zakresie.

Konfigurację przeprowadza się w interfejsie użytkownika w sekcji Settings, a następnie Models. Katalog zawiera gotowe karty dla głównych dostawców API (DeepSeek, OpenAI, Anthropic), w których należy wkleić klucz. Opcja "Add a custom provider" jest bardziej elastyczna: wymaga podania identyfikatora dostawcy, nazwy wyświetlanej, adresu base URL, protokołu API oraz danych uwierzytelniających. Obsługuje ona protokół zgodny z OpenAI, dzięki czemu działa z każdą bramą lub serwerem lokalnym implementującym ten standard. Niestandardowi dostawcy mogą również odpytywać punkt końcowy GET /models w celu automatycznego uzupełnienia listy modeli.

W ten sposób można wskazać harnessowi model działający na tym samym serwerze VPS. Ollama udostępnia API zgodne z OpenAI pod adresem http://127.0.0.1:11434/v1/ i wymaga wypełnienia pola klucza API dowolnym ciągiem znaków, zgodnie z konwencją ollama, ponieważ pole to jest wymagane, a następnie ignorowane. Pytanie o to, czy model wystarczająco mały, aby zmieścić się na serwerze VPS, jest wystarczająco wydajny do obsługi agenta, jest trudniejsze, a różnica między Ollama a vLLM jako lokalnym serwerem modeli decyduje o tym, ile pamięci RAM zajmie to rozwiązanie.

Klucze wpisane w interfejsie użytkownika są typu write-only. Harness przechowuje je w $DSH_HOME/.credentials.yaml, zachowując jedynie referencję do danych uwierzytelniających w settings.yaml. $DSH_HOME domyślnie wskazuje na ~/.dsh. Plik ten należy traktować jak plik z hasłami, ponieważ w rzeczywistości nim jest: każda osoba, która uzyska do niego dostęp, może wykorzystać budżet API.

Wymagania wstępne przed instalacją

• serwer VPS z systemem Ubuntu 24.04 lub innym aktualnym systemem Linux oraz dostępem przez SSH
• Node.js w wersji 22.19 lub nowszej z linii 22.x, bądź Node.js 24 lub nowszy, na których projekt jest budowany i testowany
• zwykłe konto użytkownika, nie root, ponieważ agent wykonuje polecenia powłoki z uprawnieniami użytkownika, który uruchomił proces
• pnpm w zmiennej PATH, jeśli planowana jest instalacja wtyczek, ponieważ polecenie wtyczki wywołuje je w powłoce
• port 3080 zamknięty na zaporze sieciowej systemu oraz na zewnętrznej zaporze sieciowej dostawcy

Pakiet nodejs w systemie Ubuntu jest starszy niż wymagania środowiska, dlatego należy zainstalować Node.js z repozytorium NodeSource lub za pomocą nvm, zamiast korzystać z apt install nodejs. Jeśli VPS jest świeżo zainstalowany, warto poświęcić dziesięć minut na zabezpieczenie SSH przed wykonaniem jakichkolwiek innych czynności, ponieważ niezawodność tunelu, z którego będziesz korzystać, zależy bezpośrednio od konfiguracji serwera SSH.

Instalacja DeepSeek Harness na serwerze VPS z przypięciem do konkretnej wersji

node --version
npx @deepseek-ai/dsh@0.1.0-rc.6 web

npx pobiera pakiet i uruchamia plik binarny dsh. web to alias dla --profile web, który uruchamia aplikację przeglądarkową, a proces wyświetla adres, na którym nasłuchuje. Wartością domyślną jest http://127.0.0.1:3080.

Przypnij wersję. npx @deepseek-ai/dsh web rozwiązuje wskazanie tagu latest w momencie uruchomienia polecenia, a projekt wydał już kilka wersji kandydackich i zapowiada zmiany powodujące niekompatybilność. 0.1.0-rc.6 to wersja, na którą wskazywał latest w dniu 13 sierpnia 2026. Przypięta wersja oznacza, że serwer skonfigurowany dzisiaj będzie zachowywał się tak samo w przyszłym miesiącu, dzięki czemu aktualizacja staje się świadomą decyzją, a nie przypadkowym odkryciem.

Do codziennego użytku zainstaluj aplikację jednorazowo, zamiast rozwiązywać wskazania przy każdym starcie.

npm install -g @deepseek-ai/dsh@0.1.0-rc.6
dsh --profile web --help

Drugą linię warto wykonać, ponieważ program uruchamiający oraz aplikacja webowa posiadają oddzielne zestawy flag. dsh --help wyświetla opcje samego launchera. dsh --profile web --help pokazuje flagi akceptowane przez aplikację webową; to tam znajdują się --port, --host oraz powtarzalna flaga --trusted-host.

Teraz potwierdź, na jakim adresie odbywa się nasłuchiwanie.

ss -tlnp | grep 3080

Kolumna adresu lokalnego powinna wskazywać 127.0.0.1:3080. Jeśli widnieje tam 0.0.0.0:3080, interfejs jest dostępny z Internetu i należy natychmiast zatrzymać proces przed podjęciem jakichkolwiek dalszych działań.

Dlaczego nigdy nie należy udostępniać portu 3080

Serwer WWW nie posiada warstwy uwierzytelniania. Jego konfiguracja określa jedynie hosta i port nasłuchiwania, co stanowi pełną powierzchnię ataku. Kontrola dostępu w wdrożeniach innych niż loopback opiera się na oddzielnym ustawieniu zaufanych hostów, które nie jest ekranem logowania.

Należy wziąć pod uwagę to, co znajduje się za tym portem. Agent edytuje pliki w obszarze roboczym i wykonuje polecenia powłoki, a poświadczenia dostawcy znajdują się na dysku w jego sąsiedztwie. Otwarty port 3080 stanowi zatem zdalną powłokę z interfejsem czatu, działającą z uprawnieniami użytkownika, który ją uruchomił, wraz z dołączonym kluczem API. Do przejęcia kontroli nie jest potrzebny żaden exploit. Wystarczy numer portu, a skanery sieciowe wykrywają otwarte porty w ciągu kilku godzin od pojawienia się hosta w Internecie.

Interfejs CLI (command line interface) uwzględnia to zagrożenie. Począwszy od wersji 0.1.0-rc.6, celowo nie obsługuje on --host 0.0.0.0 i kończy działanie błędem składni zamiast uruchomienia. Ta odmowa jest zamierzoną funkcją, dlatego nie należy szukać poprawek usuwających to ograniczenie.

Istnieją dwa inne rozsądne sposoby wdrożenia, jeśli tunelowanie nie jest odpowiednim rozwiązaniem. Można umieścić serwer w prywatnej sieci nakładkowej (overlay network), aby posiadał adres dostępny tylko dla własnych urządzeń, co zapewnia samodzielnie hostowany serwer kontrolny Headscale. Alternatywnie można zastosować reverse proxy, które uwierzytelnia żądanie przed jego dotarciem do portu 3080, na przykład poprzez serwer logowania jednokrotnego Authentik realizujący forward auth. Reverse proxy bez skonfigurowanego uwierzytelniania nie stanowi zabezpieczenia. Jest jedynie dłuższym adresem URL.

Dostęp do interfejsu WWW przez tunel SSH

Wykonaj to polecenie na swoim laptopie, a nie na serwerze.

ssh -N -L 3080:127.0.0.1:3080 you@your-server

-L otwiera port 3080 na laptopie i przesyła wszystko, co się z nim łączy, przez zaszyfrowaną sesję SSH. Część 127.0.0.1:3080 jest rozwiązywana na serwerze, więc połączenie dociera do harness z interfejsu loopback, dokładnie tak, jakby użytkownik znajdował się przy tej maszynie. -N informuje, aby nie uruchamiać zdalnej powłoki, ponieważ wymagane jest jedynie przekierowanie portu.

Następnie otwórz http://127.0.0.1:3080 w lokalnej przeglądarce. Jeśli port 3080 jest już zajęty na laptopie, zmień liczbę po lewej stronie: ssh -N -L 3180:127.0.0.1:3080 you@your-server, a następnie przejdź pod adres http://127.0.0.1:3180. Liczba po lewej stronie jest lokalna, a liczba po prawej należy do serwera, więc zmienia się tylko pierwsza z nich.

Zapisz to w ~/.ssh/config, aby nie wpisywać polecenia ponownie.

Host dsh
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  LocalForward 3080 127.0.0.1:3080

Następnie ssh -N dsh uruchamia tunel. Jeśli przeglądarka zgłasza odmowę połączenia, zazwyczaj oznacza to, że tunel działa, ale po drugiej stronie nic nie nasłuchuje, ponieważ SSH przekierowuje port niezależnie od tego, czy harness jest uruchomiony. Sprawdź serwer za pomocą polecenia ss podanego powyżej.

Utrzymanie działania środowiska po wylogowaniu

Polecenie npx kończy działanie wraz z zamknięciem powłoki. Usługa użytkownika systemd działa w tle i przywraca środowisko po awarii lub restarcie systemu.

loginctl enable-linger $USER
mkdir -p ~/.config/systemd/user
command -v dsh

enable-linger jest istotne, ponieważ usługi użytkownika są domyślnie zatrzymywane po zakończeniu ostatniej sesji. Bez tego ustawienia środowisko zostanie zamknięte w momencie przerwania tunelu. Należy użyć ścieżki bezwzględnej wyświetlonej przez command -v dsh i umieścić ją w pliku jednostki, ponieważ systemd nie przeszukuje zmiennej PATH zdefiniowanej w powłoce logowania.

[Unit]
Description=DeepSeek Harness web UI
After=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/projects/site
ExecStart=/usr/local/bin/dsh web
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

WorkingDirectory nie jest opcjonalne. Proces dsh używa katalogu, z którego został wywołany, jako domyślnej lokalizacji w systemie plików. Uruchomienie usługi z niewłaściwego miejsca spowoduje przypisanie agentowi błędnego domyślnego obszaru roboczego. Obszar roboczy można nadal wybrać w interfejsie użytkownika.

systemctl --user daemon-reload
systemctl --user enable --now dsh
systemctl --user status dsh

Jednostka, która nie chce się uruchomić, zazwyczaj wskazuje na błędną ścieżkę ExecStart lub wersję Node nieobsługiwaną przez plik binarny. Polecenie journalctl --user -u dsh -n 50 wskazuje przyczynę błędu. Ten sam schemat dotyczy utrzymywania dowolnego agenta programistycznego na serwerze VPS, a typy awarii są identyczne.

Zakres uprawnień wtyczki

Wtyczka to moduł dostarczający usługi, typowane zdarzenia oraz odwracalne efekty do współdzielonego kontekstu. Punkty rozszerzeń wymagają wnikliwej analizy:

• rejestracja dostawcy modelu w ctx.llm
• dodawanie narzędzi dla modelu w ctx.tools
• dostarczanie backendu powłoki w ctx.shell
• zapewnianie dostępu do systemu plików lub polityk w ctx.fs
• rejestracja poleceń użytkownika w ctx.commands
• wykonywanie zadań w tle przez ctx.jobs
• opakowywanie uruchamianych procesów backendem ctx.sandbox
• przechwytywanie żądań i wywołań narzędzi przez zdarzenia agent/* oraz tools/*
• rozszerzanie trwałego stanu sesji
• sterowanie interfejsem użytkownika przez ctx.agents

Należy przeanalizować tę listę z perspektywy atakującego. Wtyczka może dostarczyć warstwę systemu plików oraz warstwę powłoki, a także pośredniczyć w każdym wywołaniu narzędzia przez model. Brak okien dialogowych z prośbą o uprawnienia między wtyczką a tymi punktami styku, ponieważ wtyczka jest zwykłym kodem Node ładowanym do tego samego procesu co reszta aplikacji. Instalacja wtyczki oznacza uruchomienie obcego kodu z uprawnieniami agenta, a uprawnienia agenta są tożsame z uprawnieniami użytkownika Unix.

Jest to ta sama decyzja o zaufaniu, którą podejmuje się podczas podłączania serwera MCP do agenta na VPS, gdzie MCP oznacza model context protocol. Z tego samego powodu bezpieczne uruchamianie agenta programistycznego na VPS zaczyna się od konfiguracji konta, na którym działa proces, a nie od modelu, oraz dlatego ataki na łańcuch dostaw npm są tak dotkliwe dla serwerów: etap instalacji stanowi moment przejęcia kontroli, a system nie wyświetla żadnych ostrzeżeń.

Źródła wtyczek

Wtyczki znajdują się w profilach. Profil to nazwany zestaw przechowywany w $DSH_HOME, którego domyślną lokalizacją jest ~/.dsh. Każdy katalog profilu zawiera zainstalowane w nim wtyczki spoza głównego drzewa (out-of-tree). Interfejs CLI zarządza nimi, przekazując argumenty bezpośrednio do pnpm, przy czym katalog profilu służy jako katalog roboczy.

dsh plugin --profile web add github:deepseek-harness/turtle-ui
dsh plugin --profile web remove turtle-ui

Ponieważ argumenty docierają do pnpm w niezmienionej formie, add, remove, update oraz why działają tak samo, jak w każdym projekcie pnpm, a wtyczka może być pakietem npm lub odwołaniem do repozytorium GitHub. pnpm musi najpierw znajdować się w zmiennej PATH. W wersji Node 22 i nowszych corepack enable pnpm automatycznie dodaje ten element do ścieżki.

Wyszukiwanie odbywa się za pomocą tematu (topic) w serwisie GitHub. Autorzy wtyczek dodają temat dsh-plugin do swoich repozytoriów, a przeglądanie tego tematu pozwala na odnalezienie dostępnych rozwiązań. Temat to etykieta, którą autor przypisuje do własnego repozytorium. Nikt nie weryfikuje ani nie podpisuje tych treści, a strona tematu jest sortowana według liczby gwiazdek, co odzwierciedla popularność, a nie bezpieczeństwo.

Cztery nawyki pozwalają zachować kontrolę nad tym procesem. Przed instalacją należy zapoznać się z kodem źródłowym, ponieważ większość wtyczek jest na tyle mała, że analiza zajmuje nie więcej niż dziesięć minut. Należy przypinać konkretną wersję lub commit zamiast śledzić gałąź (branch). Środowisko uruchomieniowe (harness) powinno działać na użytkowniku, który nie posiada żadnych innych uprawnień, na serwerze VPS, który można w razie potrzeby zreinstalować. Agentowi należy nadać osobny klucz API z własnym limitem wydatków, odseparowany od klucza używanego przez usługi produkcyjne.

Jeśli przed podjęciem decyzji użytkownik woli porównać różne projekty, wielozadaniowe środowisko Omnigent rozwiązuje ten sam problem przy użyciu innej struktury, a różnice w kompromisach stają się oczywiste po rozpoczęciu korzystania z wtyczek.

Co ulega awarii jako pierwsze

Wersja Node jest zbyt stara. Projekt wymaga środowiska Node 22.19 lub nowszego z linii 22.x, bądź Node 24 i nowszych, co jest weryfikowane w testach CI. Starsze środowisko uruchomieniowe kończy działanie przy starcie, ponieważ kod wykorzystuje składnię i API, których nie obsługuje. Przed wykonaniem jakichkolwiek innych czynności uruchom node --version.

Port 3080 jest już zajęty. Przyczyną może być druga instancja narzędzia, zawieszony proces lub inna aplikacja korzystająca z portu 3080. Zidentyfikuj proces za pomocą ss -tlnp | grep 3080, a następnie zatrzymaj go lub uruchom narzędzie w innym miejscu za pomocą dsh web --port 3180. --port należy do aplikacji webowej, więc parametr ten stosuje się po web.

Przeglądarka nie może połączyć się przez tunel. Upewnij się, że nawigujesz pod adres 127.0.0.1, a nie pod publiczny adres serwera, ponieważ przekierowany port istnieje tylko na Twoim komputerze lokalnym. Następnie sprawdź, czy narzędzie nasłuchuje na serwerze, ponieważ SSH ustanawia przekierowanie niezależnie od tego, czy po drugiej stronie działa jakakolwiek usługa.

dsh plugin kończy się natychmiastowym błędem. Polecenie to jest nakładką na pnpm, więc brak pliku binarnego pnpm przerywa działanie przed rozpoczęciem pracy jakiejkolwiek wtyczki.

Agent nie widzi projektu. Obszar roboczy domyślnie ustawiany jest na katalog, w którym uruchomiono proces, więc jednostka, której WorkingDirectory wskazuje na katalog domowy, udostępnia agentowi właśnie ten katalog. Wybierz obszar roboczy w interfejsie użytkownika lub popraw konfigurację jednostki i przeładuj ją.

FAQ

Czy wystawienie interfejsu webowego DeepSeek Harness na porcie 3080 jest bezpieczne?

Nie. Serwer WWW nie posiada własnego mechanizmu logowania, a agent działający w tle edytuje pliki i wykonuje polecenia powłoki jako użytkownik, który uruchomił proces, przechowując klucz API dostawcy na tym samym dysku. Należy pozostawić nasłuchiwanie na 127.0.0.1 i uzyskiwać dostęp przez tunel SSH. Sprawdzi się również prywatna sieć nakładkowa (overlay network) lub reverse proxy, które uwierzytelnia każde żądanie przed przekazaniem go do portu. Od wersji 0.1.0-rc.6 interfejs CLI odrzuca --host 0.0.0.0 i kończy działanie błędem składni, co wskazuje na stanowisko autorów w tej kwestii.

Czy wymagany jest klucz API DeepSeek, czy można użyć modelu lokalnego?

Oba rozwiązania są poprawne, ponieważ harness jest środowiskiem uruchomieniowym, a nie modelem. W sekcji Settings, a następnie Models, można wkleić klucz do karty dostawcy w katalogu lub wybrać "Add a custom provider" i podać bazowy URL obsługujący protokół zgodny z OpenAI. Lokalny serwer Ollama odpowiada pod adresem http://127.0.0.1:11434/v1/ i akceptuje dowolny ciąg znaków w polu klucza API. Klucze są zapisywane w $DSH_HOME/.credentials.yaml, którego domyślna lokalizacja to ~/.dsh/.credentials.yaml.

Jakie uprawnienia otrzymuje wtyczka po zainstalowaniu w DeepSeek Harness?

Otrzymuje uprawnienia konta, na którym uruchomiono harness. Wtyczka to kod Node ładowany do tego samego procesu, a punkty rozszerzeń obejmują backend powłoki, warstwę systemu plików, rejestr narzędzi oraz zdarzenia otaczające każde wywołanie narzędzia. Żaden mechanizm nie izoluje wtyczki od tych elementów, chyba że sama wtyczka dostarcza własne środowisko piaskownicy (sandbox). Przed instalacją należy zapoznać się z kodem źródłowym i uruchamiać harness jako użytkownik, który nie posiada dostępu do żadnych istotnych danych.

Którą wersję zainstalować i czy będzie ona nadal działać?

Należy zainstalować konkretną wersję, na przykład npx @deepseek-ai/dsh@0.1.0-rc.6 web. Jest to wersja, na którą wskazywał tag latest w dniu 13 sierpnia 2026. Projekt jest określany jako poglądowa wersja deweloperska (developer preview), w której należy spodziewać się zmian łamiących kompatybilność, dlatego nieprzypięte polecenie może zachowywać się inaczej z dnia na dzień. Przed aktualizacją należy sprawdzić repozytorium; należy również liczyć się z tym, że klucze konfiguracyjne i interfejsy wtyczek mogą ulegać zmianom, dopóki wersja zaczyna się od 0.