Parowanie Node’ów

• Parowanie urządzenia (rola node) warunkuje uzgadnianie connect. Zobacz Automatyczne zatwierdzanie urządzeń na podstawie zaufanego CIDR poniżej oraz Parowanie kanałów.
• Zatwierdzanie możliwości Node (node.pair.*) określa, które zadeklarowane możliwości/polecenia może udostępniać połączony Node. Gateway jest źródłem prawdy; interfejsy użytkownika (aplikacja macOS, Control UI) służą do zatwierdzania lub odrzucania oczekujących żądań.

​

Jak działa zatwierdzanie możliwości

1. Node łączy się z WS Gateway (ten krok wymaga parowania urządzenia).
2. Gateway porównuje zadeklarowany zakres możliwości/poleceń z zakresem zatwierdzonym; nowe lub rozszerzone zakresy powodują zapisanie oczekującego żądania w rekordzie urządzenia i wyemitowanie node.pair.requested.
3. Żądanie zostaje zatwierdzone lub odrzucone (za pomocą CLI lub interfejsu użytkownika).
4. Do czasu zatwierdzenia polecenia Node pozostają filtrowane; zatwierdzenie udostępnia zadeklarowany zakres z uwzględnieniem standardowej polityki poleceń.

​

Przepływ pracy CLI (odpowiedni dla środowisk bez interfejsu graficznego)

openclaw nodes pending
openclaw nodes approve <requestId>
openclaw nodes reject <requestId>
openclaw nodes status
openclaw nodes remove --node <id|name|ip>
openclaw nodes rename --node <id|name|ip> --name "Living Room iPad"

​

Powierzchnia API (protokół Gateway)

• node.pair.requested — emitowane po utworzeniu nowego oczekującego żądania.
• node.pair.resolved — emitowane po zatwierdzeniu, odrzuceniu lub wygaśnięciu żądania.

• node.pair.list — wyświetla oczekujące i sparowane Node (operator.pairing).
• node.pair.approve — zatwierdza oczekujące żądanie.
• node.pair.reject — odrzuca oczekujące żądanie.
• node.pair.remove — usuwa sparowany Node. Powoduje to unieważnienie roli node urządzenia w magazynie sparowanych urządzeń, usunięcie wraz z nią zatwierdzonego zakresu Node oraz unieważnienie/rozłączenie sesji tego urządzenia z rolą Node. Urządzenie z wieloma rolami (na przykład mające również operator) zachowuje swój wiersz i traci tylko rolę node; wiersz urządzenia mającego wyłącznie rolę Node zostaje usunięty. Autoryzacja: operator.pairing może usuwać wiersze Node niebędące operatorami; obiekt wywołujący z tokenem urządzenia, który unieważnia swoją własną rolę Node na urządzeniu z wieloma rolami, dodatkowo wymaga operator.admin.
• node.rename — zmienia widoczną dla operatora nazwę wyświetlaną sparowanego Node.

• Ponowne połączenia z niezmienionym zakresem wykorzystują ponownie oczekujące żądanie; powtarzane żądania odświeżają zapisane metadane Node i najnowszy dozwolony zadeklarowany zestaw poleceń, aby operator miał aktualny wgląd.
• Poziomy zakresów operatora i kontrole wykonywane podczas zatwierdzania podsumowano w sekcji Zakresy operatora.
• node.pair.approve używa zadeklarowanych poleceń oczekującego żądania, aby wymusić dodatkowe zakresy zatwierdzania:
  • żądanie bez poleceń: operator.pairing
  • zwykłe żądanie polecenia: operator.pairing + operator.write
  • żądanie wymagające uprawnień administratora, zawierające system.run, system.run.prepare, system.which, browser.proxy, fs.listDir lub system.execApprovals.get/set: operator.pairing + operator.admin

​

Ograniczanie poleceń Node (2026.3.31+)

• Node, które wcześniej udostępniały polecenia wyłącznie na podstawie parowania urządzenia, muszą teraz również ukończyć parowanie Node.
• Polecenia umieszczone w kolejce przed zatwierdzeniem parowania są odrzucane, a nie odkładane.

​

Granice zaufania zdarzeń Node (2026.3.31+)

​

Automatyczne zatwierdzanie urządzeń zweryfikowanych przez SSH (domyślnie)

• Użytkownik procesu Gateway (lub sshVerify.user) może połączyć się przez SSH z hostem Node bez interakcji (klucze/agent; działa również Tailscale SSH), a klucz hosta jest już zaufany.
• openclaw jest rozpoznawane w zdalnym PATH dla nieinteraktywnego sh -lc.
• Adres IP połączenia jest bezpośrednim (bez pośrednika i bez interfejsu pętli zwrotnej) adresem prywatnym, ULA, lokalnym dla łącza lub CGNAT albo odpowiada sshVerify.cidrs, jeśli ustawiono tę wartość.
• Obowiązuje ten sam minimalny poziom kwalifikacji co przy zatwierdzaniu na podstawie zaufanego CIDR: tylko nowe parowanie Node bez zakresów; aktualizacje, przeglądarki, Control UI i WebChat zawsze wyświetlają monit.

{
  gateway: {
    nodes: {
      pairing: {
        // Wyłącz całkowicie:
        sshVerify: false,
        // ...lub ogranicz/dostosuj sondę:
        // sshVerify: { user: "me", identity: "~/.ssh/probe", timeoutMs: 7000, cidrs: ["10.0.0.0/8"] },
      },
    },
  },
}

​

Automatyczne zatwierdzanie (aplikacja macOS)

• żądanie jest oznaczone jako silent (Gateway oznacza pierwszy zakres możliwości jako cichy, gdy parowanie urządzenia zatwierdzono bez interakcji), oraz
• aplikacja może zweryfikować połączenie SSH z hostem Gateway przy użyciu tego samego użytkownika.

​

Automatyczne zatwierdzanie urządzeń na podstawie zaufanego CIDR

{
  gateway: {
    nodes: {
      pairing: {
        autoApproveCidrs: ["192.168.1.0/24"],
      },
    },
  },
}

• Wyłączone, gdy gateway.nodes.pairing.autoApproveCidrs nie jest ustawione.
• Nie istnieje ogólny tryb automatycznego zatwierdzania dla sieci LAN ani sieci prywatnych; automatyczne zatwierdzanie zweryfikowane przez SSH (powyżej) wymaga kryptograficznego dopasowania klucza urządzenia, a nigdy wyłącznie lokalizacji sieciowej.
• Kwalifikuje się tylko nowe żądanie parowania urządzenia role: node bez żądanych zakresów.
• Klienci operatora, przeglądarki, Control UI i WebChat pozostają obsługiwani ręcznie.
• Rozszerzenia ról, zakresów, metadanych i kluczy publicznych pozostają obsługiwane ręcznie.
• Ścieżki nagłówków zaufanego serwera proxy przez interfejs pętli zwrotnej tego samego hosta nie kwalifikują się, ponieważ lokalne obiekty wywołujące mogą sfałszować tę ścieżkę.

​

Czyszczenie zastąpionych cichych parowań

• Kwalifikują się tylko rekordy, których ostatnie zatwierdzenie było lokalne na tym samym hoście (silent) — zarówno jako wyzwalacz, jak i cel. Powiązania zweryfikowane za pomocą zaufanego zakresu CIDR i SSH obejmują różne hosty, na których metadane wyświetlania nie stanowią tożsamości maszyny, dlatego nigdy nie są usuwane automatycznie — w ich przypadku należy użyć funkcji czyszczenia w interfejsie Control UI lub polecenia openclaw nodes remove.
• Powiązania zatwierdzone przez właściciela oraz za pomocą kodu QR/kodu konfiguracji (bootstrap) nigdy nie są usuwane automatycznie. Rekordy zatwierdzone przed wprowadzeniem informacji o pochodzeniu pozostają chronione nawet po późniejszym, niewidocznym ponownym zatwierdzeniu tego samego identyfikatora urządzenia.
• Aktualnie połączone urządzenia są pomijane, dzięki czemu równoczesne sesje lokalne z oddzielnymi katalogami stanu zachowują swoje tokeny przez cały czas trwania połączenia. Pomijane są również rekordy zatwierdzone w ciągu ostatniej minuty, dzięki czemu jednoczesne uzgadnianie powiązań nie może wzajemnie ich wycofać, zanim ich połączenia zostaną zarejestrowane.
• Klienci, których to dotyczy, są z założenia lokalni, dlatego przy następnym połączeniu ponownie powiążą się bez interakcji użytkownika.

​

Automatyczne zatwierdzanie uaktualnienia metadanych

​

Narzędzia pomocnicze do powiązywania za pomocą kodu QR

​

Lokalność i nagłówki przekazywane

​

Przechowywanie (lokalne, prywatne)

• ~/.openclaw/state/openclaw.sqlite (powiązane urządzenia z uwierzytelnianiem urządzenia, zatwierdzone powierzchnie Node, oczekujące żądania powierzchni, oczekujące żądania powiązania urządzeń oraz tokeny bootstrap)

• Tokeny urządzeń są danymi poufnymi; bazę danych stanu należy traktować jako wrażliwą.
• Do rotacji tokena urządzenia służy openclaw devices rotate / device.token.rotate.

​

Działanie transportu

• Transport jest bezstanowy; nie przechowuje informacji o przynależności.
• Jeśli Gateway jest offline lub powiązywanie jest wyłączone, węzły nie mogą się powiązać.
• W trybie zdalnym powiązywanie odbywa się względem magazynu zdalnego Gateway.

​

Powiązane materiały

• Powiązywanie kanałów
• CLI węzłów
• CLI urządzeń