SSH invers pentru un singur dispozitiv: listener loopback sau VPN rutat?

Dispozitivul dvs. stă în spatele NAT-ului unui operator, poate deschide conexiuni de ieșire și rulează un server SSH la care nimeni nu poate ajunge. Cererea care sosește este de obicei formulată ca "dați-i un VPN", ceea ce este un răspuns dintre mai multe. Înainte să o acceptați, decideți dacă aveți nevoie de un singur port TCP administrativ sau de o cale rutată către o întreagă subrețea, pentru că sunt proiecte diferite cu expunere diferită.

Un tunel invers răspunde bine versiunii înguste. Dispozitivul apelează hubul dvs., cere hubului să asculte pe un port loopback și redirecționează acel port înapoi către propriul serviciu SSH. Apoi administratorii ajung la listener prin hub, nu prin internetul public.

Trei condiții care decid alegerea

Notați-le înainte de orice configurare. Ele sunt granița dintre o intrare de administrare limitată și o extindere de rețea, iar amestecarea lor este modul în care un tunel de cinci linii devine o rețea plată fără proprietar.

Al treilea rând este cel despre care oamenii se ceartă. Un tunel către portul SSH al unui dispozitiv nu îi pune vecinii în rețeaua dvs. și nu ar trebui să pară că o face printr-un lanț de redirecționări suplimentare. Dacă cerința este într-adevăr LAN-ul, spuneți-o și proiectați-l pe acela în schimb.

Partea hubului: un cont de releu limitat

Dați fiecărui dispozitiv propriul cont de releu cu autentificare prin cheie publică și fără sesiune interactivă. Match blocul limitat la acel cont ține permisiunea mică, iar cheia privată rămâne pe dispozitivul unde îi este locul.

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

MaxSessions 0 este linia interesantă. Refuză sesiunile de shell și de subsisteme, permițând în continuare redirecționarea de care are nevoie dispozitivul, așa că o cheie furată nu poate fi transformată într-o conectare interactivă. PermitListen fixează adresa și portul listenerului pe partea hubului, și GatewayPorts no îl ține pe loopback în loc să îl deschidă către rețeaua în care se află hubul.

Testați configurația efectivă înainte de reîncărcare și țineți o a doua sesiune deschisă în timp ce faceți asta. Match blocul care se aplică accidental tuturor, sau o greșeală de tastare într-un nume de opțiune, este modul clasic de a vă încuia în afara mașinii pe care o întăriți. Afișați configurația curentă și recitiți opțiunile în loc să aveți încredere în fișierul pe care tocmai l-ați scris. Rețineți că suportul opțiunilor diferă între versiuni, așa că o linie acceptată într-un server mai nou poate fi pur și simplu ignorată de unul mai vechi.

Partea dispozitivului: redirecționare care eșuează zgomotos

Dispozitivul deschide conexiunea și cere listenerul. Cele două adrese din argument -R înseamnă lucruri diferite, iar citirea lor de la stânga la dreapta este cea mai rapidă cale de a reține care este care.

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

Perechea stângă este locul unde hubul ar trebui să asculte. Perechea dreaptă este ceea ce dispozitivul accesează când sosește o cerere, rezolvată din partea dispozitivului însuși. Inversarea lor produce un tunel care urcă curat și redirecționează în locul greșit, ceea ce este mai rău decât un eșec.

ExitOnForwardFailure=yes face comanda să se închidă atunci când listenerul cerut nu poate fi stabilit, așa că o buclă de repornire vă spune adevărul în loc să lase o sesiune pe jumătate funcțională. Nu spune nimic despre sănătatea serviciului SSH local mai târziu, așa că asociați-l cu un manager de procese și cu un test real de conexiune din când în când.

Nu înlocuiți niciodată adresa de ascultare loopback cu un wildcard pentru a evita un salt suplimentar. Acea singură schimbare este diferența dintre o cale de administrare și un port accesibil public, și de obicei se întâmplă în timpul depanării și apoi rămâne. Dacă un coleg nu ajunge la port prin hub, reparați configurația saltului în loc să lărgiți legătura. Loopback este întregul argument de securitate al acestui design.

Acces de administrator prin hub

Un administrator cu un cont obișnuit pe hub poate sări prin el la portul redirecționat. Contul de releu nu este folosit pentru asta, și exact acesta este rostul de a le ține separate.

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

Verificați cheia de gazdă a dispozitivului sub aliasul pe care l-ați ales, pentru că acea cheie identifică dispozitivul la capătul lanțului, iar tunelul este doar transport. Conectarea de la un capăt la altul autentifică în continuare ambele capete; un tunel care se termină pe un hub partajat nu îl face de la sine o cale de încredere.

Asumați-vă ciclul de viață

Rulați comanda dispozitivului sub un manager de procese cu exact o instanță activă și o politică de repornire pe care ați ales-o deliberat. Opțiunile keepalive detectează un partener mort; ele nu readuc la viață un proces care a ieșit.

Apoi scrieți procedura de scoatere din uz. Fiecare dispozitiv primește propriul listener și propria cheie, așa că scoaterea din uz înseamnă revocarea acelui cont și eliminarea acelei chei, nu rotirea unui secret comun întregii flote.

În final, amintiți-vă ce vă oferă loopback. Limitează expunerea la rețea și nu face nimic pentru alți utilizatori locali de pe un hub partajat, așa că politica de acces a hubului însuși trebuie să rămână corectă. Referință sshd_config documentează fiecare dintre opțiunile folosite mai sus, și merită să citiți integral secțiunile despre redirecționare înainte de a lărgi vreuna dintre ele.