Omvendt SSH for én enhet: loopback-lytter eller rutet VPN?

Enheten din står bak en leverandør-NAT, den kan åpne utgående forbindelser, og den kjører en SSH-server som ingen kan nå. Forespørselen som kommer, formuleres vanligvis som "gi den en VPN", som er ett svar blant flere. Før du godtar det, må du avgjøre om du trenger én administrativ TCP-port eller en rutet vei til et helt subnett, fordi det er forskjellige prosjekter med forskjellig eksponering.

En omvendt tunnel svarer godt på den smale versjonen. Enheten ringer opp huben din, ber huben lytte på en loopback-port og videresender den porten tilbake til sin egen SSH-tjeneste. Deretter når administratorer lytteren gjennom huben, ikke gjennom det offentlige internettet.

Tre betingelser som avgjør valget

Skriv dem ned før noen konfigurasjon. De er grensen mellom en avgrenset administrasjonsinngang og en nettverksutvidelse, og å blande dem er hvordan en tunnel på fem linjer blir et eierløst flatt nettverk.

Den tredje raden er den folk diskuterer. En tunnel til en enhets SSH-port setter ikke naboene på nettverket ditt, og det bør ikke få det til å se slik ut gjennom en kjede av videre videresendinger. Hvis kravet virkelig er LAN-et, si det og design det i stedet.

Hub-siden: en avgrenset relay-konto

Gi hver enhet sin egen relay-konto med offentlig nøkkel-autentisering og uten interaktiv økt. Match blokk begrenset til den kontoen holder tillatelsen liten, og den private nøkkelen blir på enheten der den hører hjemme.

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 linjen. Den nekter shell- og undersystemøkter mens den fortsatt tillater videresendingen enheten trenger, slik at en stjålet nøkkel ikke kan gjøres om til en interaktiv innlogging. PermitListen fester adressen og porten til lytteren på hub-siden, og GatewayPorts no holder den på loopback i stedet for å åpne den mot nettverket huben står på.

Test den effektive konfigurasjonen før du laster på nytt, og hold en andre økt åpen mens du gjør det. Match blokk som ved et uhell gjelder for alle, eller en skrivefeil i et opsjonsnavn, er den klassiske måten å låse seg ute av boksen du herder. Dumpe den kjørende konfigurasjonen og les opsjonene tilbake i stedet for å stole på filen du nettopp skrev. Vær oppmerksom på at opsjonsstøtte varierer mellom bygg, slik at en linje som godtas i en nyere server, rett og slett kan ignoreres av en eldre.

Enhetssiden: videresending som feiler høylytt

Enheten åpner forbindelsen og ber om lytteren. De to adressene i argumentet -R betyr forskjellige ting, og å lese dem fra venstre mot høyre er den raskeste måten å huske hvilken som 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 paret er der huben skal lytte. Det høyre paret er det enheten kobler til når en forespørsel kommer, løst fra enhetens egen side. Å bytte dem gir en tunnel som kommer rent opp og videresender til feil sted, noe som er verre enn en feil.

ExitOnForwardFailure=yes får kommandoen til å avslutte når den forespurte lytteren ikke kan etableres, slik at en omstartssløyfe forteller deg sannheten i stedet for å etterlate en halvfungerende økt. Den sier ingenting om hvorvidt den lokale SSH-tjenesten er sunn senere, så koble den sammen med en prosessbehandler og en sporadisk ekte tilkoblingstest.

Erstatt aldri loopback-lytteadressen med et jokertegn for å unngå et ekstra hopp. Den ene endringen er forskjellen mellom en administrasjonsvei og en offentlig tilgjengelig port, og den skjer vanligvis under feilsøking og blir deretter. Hvis en kollega ikke når porten gjennom huben, reparer jump-konfigurasjonen i stedet for å utvide bindingen. Loopback er hele sikkerhetsargumentet for dette designet.

Administratortilgang gjennom huben

En administrator med en vanlig konto på huben kan hoppe gjennom den til den videresendte porten. Relay-kontoen brukes ikke til dette, og det er nettopp poenget med å holde dem atskilt.

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

Verifiser enhetens vertsnøkkel under aliaset du valgte, fordi den nøkkelen identifiserer enheten i enden av kjeden, og tunnelen er bare transport. Innloggingen ende til ende autentiserer fortsatt begge ender; en tunnel som ender på en delt hub, gjør den ikke i seg selv til en betrodd vei.

Ta eierskap til livssyklusen

Kjør enhetskommandoen under en prosessbehandler med nøyaktig én aktiv instans og en omstartspolicy du har valgt bevisst. Keepalive-opsjonene oppdager en død motpart; de gjenoppliver ikke en prosess som har avsluttet.

Skriv deretter nedleggelsesprosedyren. Hver enhet får sin egen lytter og sin egen nøkkel, så avvikling betyr å tilbakekalle den kontoen og fjerne den nøkkelen, ikke å rotere en hemmelighet hele flåten deler.

Til slutt, husk hva loopback gir deg. Det begrenser nettverkseksponering og gjør ingenting med andre lokale brukere på en delt hub, så hubens egen tilgangspolicy må fortsatt være riktig. sshd_config-referanse dokumenterer hver av opsjonene som er brukt ovenfor, og det er verdt å lese videresendingsavsnittene i sin helhet før du utvider noen av dem.