Omgekeerde SSH vir een toestel: loopback-luisteraar of gerouteerde VPN?

Jou toestel sit agter 'n draer-NAT, dit kan uitwaartse verbindings oopmaak, en dit bedryf 'n SSH-bediener wat niemand kan bereik nie. Die versoek wat inkom, word gewoonlik as "gee dit 'n VPN" verwoord, wat een antwoord onder verskeie is. Voordat jy dit aanvaar, besluit of jy een administratiewe TCP-poort nodig het of 'n gerouteerde pad na 'n hele subnet, want dit is verskillende projekte met verskillende blootstelling.

'n Omgekeerde tonnel beantwoord die nou weergawe goed. Die toestel skakel na jou hub, vra die hub om op 'n loopback-poort te luister, en stuur daardie poort terug na sy eie SSH-diens. Administrateurs bereik dan die luisteraar deur die hub, nie deur die publieke internet nie.

Drie voorwaardes wat die keuse beslis

Skryf dit neer voordat jy enigiets konfigureer. Hulle is die grens tussen 'n beperkte bestuursingang en 'n netwerkuitbreiding, en om hulle te verwar is hoe 'n tonnel van vyf reëls in 'n onbeheerde plat netwerk verander.

Die derde ry is die een waaroor mense stry. 'n Tonnel na 'n toestel se SSH-poort plaas nie sy bure op jou netwerk nie, en dit moet nie laat lyk asof dit dit doen deur 'n ketting van verdere aansturings nie. As die vereiste werklik die LAN is, sê dit en ontwerp eerder dit.

Hub-kant: 'n beperkte aflosrekening

Gee elke toestel sy eie aflosrekening met publieke-sleutel-verifikasie en geen interaktiewe sessie nie. Match blok wat op daardie rekening beperk is, hou die toestemming klein, en die private sleutel bly op die toestel waar dit hoort.

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 is die interessante reël. Dit weier shell- en substelselsessies terwyl dit steeds die aansturing toelaat wat die toestel nodig het, so 'n gesteelde sleutel kan nie in 'n interaktiewe aanmelding omskep word nie. PermitListen pen die hub-kant luisteraaradres en -poort vas, en GatewayPorts no hou dit op loopback in plaas daarvan om dit oop te maak vir die netwerk waarop die hub sit.

Toets die effektiewe konfigurasie voordat jy herlaai, en hou 'n tweede sessie oop terwyl jy dit doen. Match blok wat per ongeluk op almal van toepassing is, of 'n tikfout in 'n opsienaam, is die klassieke manier om jouself uit die boks te sluit wat jy harden. Gooi die lopende konfigurasie uit en lees die opsies terug eerder as om die lêer te vertrou wat jy pas geskryf het. Let daarop dat opsie-ondersteuning tussen bouwe verskil, so 'n aanvaarde reel in 'n nuwer bediener kan bloot deur 'n ouer een geïgnoreer word.

Toestelkant: aansturing wat hardop misluk

Die toestel maak die verbinding oop en versoek die luisteraar. Die twee adresse in die -R argument beteken verskillende dinge, en om dit van links na regs te lees is die vinnigste manier om te onthou watter een watter is.

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

Die linkerpaar is waar die hub moet luister. Die regterpaar is waarmee die toestel verbind wanneer 'n versoek opdaag, vanaf die toestel se eie kant opgelos. Om hulle om te ruil lewer 'n tonnel wat skoon opkom en na die verkeerde plek aanstuur, wat erger is as 'n mislukking.

ExitOnForwardFailure=yes laat die opdrag beëindig wanneer die gevraagde luisteraar nie gevestig kan word nie, so 'n herbegin-lus vertel jou die waarheid eerder as om 'n halfwerkende sessie te los. Dit se niks oor of die plaaslike SSH-diens later gesond is nie, so paar dit met 'n prosesbestuurder en 'n af en toe werklike verbindingstoets.

Moet nooit die loopback-luisteradres deur 'n wildcard vervang om 'n ekstra hop te vermy nie. Daardie enkele verandering is die verskil tussen 'n bestuurspad en 'n publiek bereikbare poort, en dit gebeur gewoonlik tydens foutsoeking en bly dan. As 'n kollega nie die poort deur die hub kan bereik nie, herstel eerder die springkonfigurasie as om die binding te verbreed. Loopback is die hele sekuriteitsargument vir hierdie ontwerp.

Administrateurtoegang deur die hub

'n Administrateur met 'n gewone rekening op die hub kan daardeur na die aangestuurde poort spring. Die aflosrekening word nie hiervoor gebruik nie, wat juis die punt is om hulle apart te hou.

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

Verifieer die toestel se gasheersleutel onder die alias wat jy gekies het, want daardie sleutel identifiseer die toestel aan die einde van die ketting en die tonnel is net vervoer. Die end-tot-end-aanmelding verifieer steeds beide kante; 'n tonnel wat op 'n gedeelde hub eindig, maak dit nie op sigself 'n vertroude pad nie.

Neem eienaarskap van die lewensiklus

Bestuur die toestelopdrag onder 'n prosesbestuurder met presies een aktiewe instansie en 'n herbeginbeleid wat jy doelbewus gekies het. Die lewend-hou-opsies bespeur 'n dooie eweknie; hulle wek nie 'n proses wat afgesluit het, weer nie.

Skryf dan die aftree-prosedure. Elke toestel kry sy eie luisteraar en sy eie sleutel, so buitestelling beteken om daardie rekening te herroep en daardie sleutel te verwyder, nie om 'n vlootwye geheim te roteer wat elke ander toestel deel nie.

Onthou laastens wat loopback vir jou koop. Dit beperk netwerkblootstelling en doen niks aan ander plaaslike gebruikers op 'n gedeelde hub nie, so die hub se eie toegangsbeleid moet steeds reg wees. Die sshd_config-verwysing dokumenteer elkeen van die opsies hierbo gebruik, en dit is die moeite werd om die aansturingsafdelings volledig te lees voordat jy enige van hulle verbreed.