Fordított SSH egyetlen eszközhöz: loopback-figyelő vagy irányított VPN?

Az eszköz egy szolgáltató NAT-ja mögött van, tud kimenő kapcsolatokat nyitni, és olyan SSH-kiszolgálót futtat, amelyet senki sem ér el. A beérkező kérés általában úgy fogalmazódik meg, hogy "adjon neki VPN-t", ami egy válasz a sok közül. Mielőtt elfogadja, döntse el, hogy egyetlen felügyeleti TCP-portra van szüksége, vagy irányított útra egy egész alhálózathoz, mert ezek különböző projektek különböző kitettséggel.

A fordított alagút jól válaszol a szűk változatra. Az eszköz tárcsázza a hubját, megkéri a hubot, hogy figyeljen egy loopback-porton, és továbbítja azt a portot a saját SSH-szolgáltatására. Ezután az adminisztrátorok a hubon keresztül érik el a figyelőt, nem a nyilvános interneten keresztül.

Három feltétel, amely eldönti a választást

Írja le őket bármilyen konfiguráció előtt. Ezek a határvonal a korlátozott felügyeleti belépés és a hálózatbővítés között, és ezek összekeverése az, ahogy egy ötsoros alagút gazdátlan lapos hálózattá válik.

A harmadik sor az, amiről az emberek vitatkoznak. Az eszköz SSH-portjára mutató alagút nem teszi be a szomszédait a hálózatára, és nem is szabad úgy tüntetni fel, mintha további továbbítások láncán keresztül tenné. Ha a követelmény valóban a LAN, mondja ki, és tervezze meg inkább azt.

Hub oldal: korlátozott relay-fiók

Adjon minden eszköznek saját relay-fiókot nyilvános kulcsos hitelesítéssel és interaktív munkamenet nélkül. Match blokk, amely erre a fiókra korlátozódik, kicsiben tartja az engedélyt, és a privát kulcs azon az eszközön marad, ahová tartozik.

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 az érdekes sor. Megtagadja a shell- és alrendszer-munkameneteket, miközben továbbra is engedi az eszköz által igényelt továbbítást, így egy ellopott kulcsot nem lehet interaktív bejelentkezéssé alakítani. PermitListen rögzíti a hub oldali figyelő címét és portját, és GatewayPorts no loopbacken tartja, ahelyett hogy megnyitná annak a hálózatnak, amelyen a hub található.

Tesztelje a hatékony konfigurációt újratöltés előtt, és tartsa nyitva közben a második munkamenetet. Match blokk, amely véletlenül mindenkire vonatkozik, vagy egy elírás egy beállítás nevében, a klasszikus módja annak, hogy kizárja magát a dobozból, amelyet keményít. Öntse ki a futó konfigurációt, és olvassa vissza a beállításokat, ahelyett hogy megbízna az imént írt fájlban. Vegye figyelembe, hogy a beállítások támogatása buildenként eltér, így egy újabb kiszolgálón elfogadott sor egy régebbi által egyszerűen figyelmen kívül maradhat.

Eszköz oldal: továbbítás, amely hangosan meghiúsul

Az eszköz megnyitja a kapcsolatot, és kéri a figyelőt. Az argumentumban szereplő két cím -R különböző dolgokat jelent, és balról jobbra olvasásuk a leggyorsabb módja annak megjegyzésére, melyik melyik.

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

A bal oldali pár az, ahol a hubnak figyelnie kell. A jobb oldali pár az, amihez az eszköz csatlakozik, amikor kérés érkezik, az eszköz saját oldaláról feloldva. Felcserélésük olyan alagutat hoz létre, amely tisztán feljön, és rossz helyre továbbít, ami rosszabb a meghiúsulásnál.

ExitOnForwardFailure=yes kilépésre készteti a parancsot, ha a kért figyelő nem hozható létre, így az újraindítási hurok megmondja az igazat, ahelyett hogy félműködő munkamenetet hagyna. Semmit sem mond arról, hogy a helyi SSH-szolgáltatás később egészséges-e, ezért párosítsa folyamatkezelővel és alkalmi valódi kapcsolatteszttel.

Soha ne cserélje le a loopback figyelési címét helyettesítő karakterre egy extra ugrás elkerülése érdekében. Ez az egyetlen változás a különbség a felügyeleti útvonal és a nyilvánosan elérhető port között, és általában hibakeresés közben történik, majd marad. Ha egy kolléga nem éri el a portot a hubon keresztül, javítsa az ugrás konfigurációját, ne pedig szélesítse a kötést. A loopback az egész biztonsági érv e mögött a terv mögött.

Adminisztrátori hozzáférés a hubon keresztül

A hubon közönséges fiókkal rendelkező adminisztrátor átugorhat rajta a továbbított portra. A relay-fiókot erre nem használják, és éppen ez az értelme annak, hogy külön tartsák őket.

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

Ellenőrizze az eszköz gazdagépkulcsát a választott álnév alatt, mert az a kulcs azonosítja az eszközt a lánc végén, és az alagút csak szállítás. A végponttól végpontig tartó bejelentkezés továbbra is mindkét véget hitelesíti; a megosztott hubon végződő alagút önmagában nem teszi megbízható útvonallá.

Vegye át az életciklus tulajdonjogát

Futtassa az eszközparancsot folyamatkezelő alatt pontosan egy aktív példánnyal és egy szándékosan választott újraindítási házirenddel. A keepalive beállítások észlelik a halott partnert; nem támasztanak fel egy kilépett folyamatot.

Ezután írja meg a kivonási eljárást. Minden eszköz saját figyelőt és saját kulcsot kap, így a leszerelés azt jelenti, hogy visszavonja azt a fiókot és eltávolítja azt a kulcsot, nem pedig egy flotta-szintű titkot forgat.

Végül emlékezzen arra, mit ad a loopback. Korlátozza a hálózati kitettséget, és semmit sem tesz a megosztott hub többi helyi felhasználójával, így a hub saját hozzáférési szabályzatának továbbra is helyesnek kell lennie. sshd_config-referencia dokumentálja a fent használt beállítások mindegyikét, és érdemes a továbbítási fejezeteket teljesen elolvasni, mielőtt bármelyiket kiszélesíti.