Omvendt SSH til én enhed: loopback-lytter eller ruteret VPN?

Din enhed står bag en udbyder-NAT, den kan åbne udgående forbindelser, og den kører en SSH-server, som ingen kan nå. Den anmodning, der kommer, formuleres normalt som "giv den en VPN", hvilket er ét svar blandt flere. Før du accepterer det, skal du beslutte, om du har brug for én administrativ TCP-port eller en ruteret vej til et helt subnet, fordi det er forskellige projekter med forskellig eksponering.

En omvendt tunnel svarer godt på den snævre version. Enheden ringer op til dit hub, beder hubbet om at lytte på en loopback-port og videresender den port tilbage til sin egen SSH-tjeneste. Derefter når administratorer lytteren gennem hubbet, ikke gennem det offentlige internet.

Tre betingelser, der afgør valget

Skriv dem ned før enhver konfiguration. De er grænsen mellem en afgrænset administrationsindgang og en netværksudvidelse, og at blande dem er, hvordan en tunnel på fem linjer bliver til et ejerløst fladt netværk.

Den tredje række er den, folk diskuterer. En tunnel til en enheds SSH-port sætter ikke dens naboer på dit netværk, og det bør ikke få det til at se sådan ud gennem en kæde af yderligere videresendelser. Hvis kravet virkelig er LAN'et, så sig det og design det i stedet.

Hub-siden: en afgrænset relay-konto

Giv hver enhed sin egen relay-konto med offentlig nøgle-autentificering og ingen interaktiv session. Match blok begrænset til den konto holder tilladelsen lille, og den private nøgle bliver på enheden, hvor den hører til.

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 er den interessante linje. Det afviser shell- og undersystem-sessioner, mens det stadig tillader den videresendelse, enheden har brug for, så en stjålen nøgle kan ikke gøres til et interaktivt login. PermitListen fastlåser lytterens adresse og port på hub-siden, og GatewayPorts no holder den på loopback i stedet for at åbne den til det netværk, hubbet står på.

Test den effektive konfiguration, før du genindlæser, og hold en anden session åben, mens du gør det. Match blok, der ved et uheld gælder for alle, eller en tastefejl i et optionsnavn, er den klassiske måde at låse dig selv ude af den maskine, du hærder. Dump den kørende konfiguration, og læs valgmulighederne tilbage i stedet for at stole på den fil, du netop har skrevet. Bemærk, at option-support er forskellig mellem builds, så en accepteret linje i en nyere server kan blot ignoreres af en ældre.

Enhedssiden: videresendelse, der fejler højlydt

Enheden åbner forbindelsen og anmoder om lytteren. De to adresser i argumentet -R betyder forskellige ting, og at læse dem fra venstre mod højre er den hurtigste måde at huske, hvilken der er hvilken.

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

Det venstre par er, hvor hubbet skal lytte. Det højre par er, hvad enheden forbinder til, når en anmodning kommer, løst fra enhedens egen side. At bytte dem giver en tunnel, der kommer rent op og videresender til det forkerte sted, hvilket er værre end en fejl.

ExitOnForwardFailure=yes får kommandoen til at afslutte, når den ønskede lytter ikke kan etableres, så en genstartsloop fortæller dig sandheden i stedet for at efterlade en halvt fungerende session. Det siger intet om, hvorvidt den lokale SSH-tjeneste er sund senere, så kobl det med en procesmanager og en lejlighedsvis rigtig forbindelsestest.

Erstat aldrig loopback-lytteadressen med et jokertegn for at undgå et ekstra hop. Den ene ændring er forskellen mellem en administrationsvej og en offentligt tilgængelig port, og den sker normalt under fejlfinding og bliver så. Hvis en kollega ikke kan nå porten gennem hubbet, så ret jump-konfigurationen i stedet for at udvide bindingen. Loopback er hele sikkerhedsargumentet for dette design.

Adgang for administratorer gennem hubbet

En administrator med en almindelig konto på hubbet kan hoppe gennem det til den videresendte port. Relay-kontoen bruges ikke til dette, og det er netop pointen i at holde dem adskilt.

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

Verificer enhedens værtsnøgle under det alias, du valgte, fordi den nøgle identificerer enheden i den anden ende af kæden, og tunnelen er kun transport. Login fra ende til ende autentificerer stadig begge ender; en tunnel, der ender på et delt hub, gør den ikke i sig selv til en betroet vej.

Tag ejerskab over livscyklussen

Kør enhedskommandoen under en procesmanager med præcis én aktiv instans og en genstartspolitik, du har valgt bevidst. Keepalive-valgmulighederne opdager en død partner; de genopliver ikke en proces, der er afsluttet.

Skriv derefter nedtagelsesproceduren. Hver enhed får sin egen lytter og sin egen nøgle, så afvikling betyder at tilbagekalde den konto og fjerne den nøgle, ikke at rotere en hemmelighed, som hele flåden deler.

Til sidst skal du huske, hvad loopback giver dig. Det begrænser netværkseksponering og gør intet ved andre lokale brugere på et delt hub, så hubbets egen adgangspolitik skal stadig være rigtig. sshd_config-reference dokumenterer hver af de valgmuligheder, der er brugt ovenfor, og det er værd at læse videresendelsesafsnittene helt, før du udvider nogen af dem.