Jak Home Assistant uwierzytelnia sesje lokalne i zdalne?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

How Does Home Assistant Authenticate Local and Remote Sessions?

Home Assistant zwykle nie tworzy jednego systemu uwierzytelniania dla sieci LAN i drugiego dla dostępu zdalnego. Użytkownik uwierzytelnia się w instancji Home Assistant, aplikacje otrzymują tokeny, a tokeny te uwierzytelniają sesje API lub WebSocket niezależnie od tego, czy żądanie przychodzi przez lokalny adres URL, Home Assistant Cloud, VPN czy odwrotne proxy.

To, co zmienia się między użyciem lokalnym a zdalnym, to przede wszystkim ścieżka sieciowa: DNS, TLS, proxy, tunelowanie i dostępność publiczna. Rozdzielenie trasy od tożsamości jest ważne, ponieważ niedziałający zdalny adres URL może wyglądać jak problem z logowaniem, nawet gdy dane uwierzytelniające użytkownika Home Assistant i tokeny są nadal prawidłowe.

Aplikacje uwierzytelniają się raz i otrzymują tokeny dostępu oraz odświeżania

Przepływ uwierzytelniania aplikacji Home Assistant generuje kod autoryzacyjny, a następnie token dostępu i token odświeżania. Krótkotrwały token dostępu służy do wykonywania wywołań API, natomiast token odświeżania pozwala aplikacji poprosić o nowy token dostępu bez konieczności logowania użytkownika podczas każdej sesji.

Aktualna dokumentacja interfejsu API uwierzytelniania opisuje przepływ autoryzacji, tokenu dostępu, tokenu odświeżania i tokenu Bearer HTTP. Gdy token dostępu przestaje być ważny, żądanie do interfejsu API HTTP zwraca kod 401, a klient powinien odświeżyć token lub ponownie przeprowadzić autoryzację.

Rozdziela to długoterminową autoryzację użytkownika od krótkiego czasu życia konkretnego poświadczenia API.

Sesje WebSocket uwierzytelniają się przed rozpoczęciem przesyłania danych na żywo

Frontend i wiele aplikacji utrzymują otwarte połączenie WebSocket, aby Home Assistant mógł przesyłać aktualizacje stanów i zdarzeń bez odpytywania serwera przy każdej zmianie.

Interfejs API WebSocket Home Assistant definiuje wyraźny etap uwierzytelniania: serwer wysyła komunikat auth_required, klient zwraca token dostępu, a dopiero odpowiedź auth_ok przenosi połączenie do etapu obsługi poleceń.

Nieprawidłowy token kończy tę sesję. Limit czasu sieci przed rozpoczęciem wymiany uwierzytelniającej jest innym błędem niż odpowiedź auth_invalid po otrzymaniu tokenu przez serwer.

Dostęp zdalny zmienia sposób, w jaki klient łączy się z Home Assistant

Domyślnie Home Assistant działa lokalnie. Dostęp zdalny można zapewnić przez Home Assistant Cloud, VPN, odwrotne proxy lub celowo zabezpieczoną ścieżkę bezpośrednią. Każda z tych opcji zmienia routing i zakres ekspozycji, ale miejscem docelowym nadal jest ta sama instancja Home Assistant.

Aktualny przewodnik dotyczący dostępu zdalnego rozróżnia trasy wykorzystujące Cloud, VPN, odwrotne proxy i przekierowanie portów. Odwrotne proxy wprowadzają także granicę zaufania, ponieważ Home Assistant musi wiedzieć, któremu proxy wolno dostarczać przekazywane informacje o żądaniu.

Dlatego zmiana routera, DNS, certyfikatu lub proxy może przerwać dostęp zdalny bez konieczności ponownego tworzenia użytkowników.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Sesje lokalne i zdalne mogą wiązać się z różnym ryzykiem sieciowym

Połączenie z sieci LAN może pozostać w zaufanej sieci domowej, podczas gdy połączenie zdalne przechodzi przez publiczny internet lub sieć nakładkową. Bezpieczny dostęp zdalny wymaga więc dodatkowego szyfrowania, wzmocnienia zabezpieczeń proxy, zasad VPN i uwierzytelniania wieloskładnikowego wokół tego samego systemu kont Home Assistant.

Nie należy interpretować określenia „ten sam model uwierzytelniania” jako „taka sama ekspozycja sieciowa”. Bezpośrednio wystawiony port publiczny, zarządzany tunel chmurowy i prywatny VPN mają różne powierzchnie ataku, nawet jeśli wszystkie ostatecznie przesyłają tokeny dostępu Home Assistant.

Przewodnik ZimaSpace dotyczący bezpieczeństwa zdalnego dostępu opisuje szerszą granicę sieciową, która pomaga zdecydować, którą ścieżką powinny być przesyłane uwierzytelnione sesje.

Oddzielaj awarie trasy od awarii uwierzytelniania

Objaw	Prawdopodobna warstwa	Pierwsze rozróżnienie
Zdalna nazwa hosta nie jest rozpoznawana	DNS / trasa	Uwierzytelnianie jeszcze się nie rozpoczęło
Błąd TLS lub proxy przed logowaniem	Zdalna ścieżka dostępu	Przetestuj bezpośredni dostęp lokalny
Interfejs API Home Assistant zwraca HTTP 401	Token / uwierzytelnianie	Odśwież token lub ponownie autoryzuj klienta
WebSocket zwraca auth_invalid	Token / uwierzytelnianie	Sprawdź autoryzację klienta
Dostęp lokalny działa, a zdalna trasa nie	DNS/VPN/proxy/NAT	Nie resetuj najpierw użytkowników

Najlepszy model mentalny to: najpierw tożsamość, następnie token sesji, a na końcu trasa sieciowa. Klienci lokalni i zdalni mogą wchodzić przez zupełnie różne ścieżki sieciowe, ale po dotarciu do instancji nadal potrzebują prawidłowej autoryzacji Home Assistant.

FAQ

Czy zdalny dostęp do Home Assistant wymaga innego hasła lub konta?

Nie. Klienci zdalni zwykle uwierzytelniają się w tym samym systemie użytkowników Home Assistant. Metoda zdalnego dostępu zmienia sposób dotarcia klienta do instancji, a nie bazę użytkowników, w której przechowywane jest konto.

Czy należy usuwać tokeny, gdy przestaje działać tylko zdalny adres URL?

Nie jako pierwszy krok. Najpierw upewnij się, że DNS, VPN, proxy, TLS lub NAT umożliwiają dotarcie do Home Assistant. Resetuj tokeny lub ponownie przeprowadzaj autoryzację, gdy sam Home Assistant odrzuca uwierzytelnianie, a nie tylko dlatego, że ścieżka sieciowa jest niedostępna.