Omvänd SSH för en enda enhet: loopback-lyssnare eller routad VPN?

Din enhet sitter bakom en leverantörs-NAT, den kan öppna utgående anslutningar och den kör en SSH-server som ingen kan nå. Förfrågan som kommer formuleras oftast som "ge den ett VPN", vilket är ett svar bland flera. Innan du accepterar det måste du avgöra om du behöver en enda administrativ TCP-port eller en routad väg till ett helt subnät, eftersom det är olika projekt med olika exponering.

En omvänd tunnel svarar bra på den smala versionen. Enheten ringer upp din hubb, ber hubben lyssna på en loopback-port och vidarebefordrar den porten tillbaka till sin egen SSH-tjänst. Därefter når administratörer lyssnaren genom hubben, inte genom det publika internet.

Tre villkor som avgör valet

Skriv ned dem före varje konfiguration. De är gränsen mellan en avgränsad administrationsväg och en nätverksutbyggnad, och att blanda ihop dem är hur en tunnel på fem rader blir ett ägarlöst platt nätverk.

Den tredje raden är den folk diskuterar. En tunnel till en enhets SSH-port sätter inte dess grannar på ditt nätverk, och det bör inte få se ut som om den gör det genom en kedja av ytterligare vidarebefordringar. Om kravet verkligen är LAN:et, säg det och designa det i stället.

Hubsidan: ett avgränsat relay-konto

Ge varje enhet sitt eget relay-konto med autentisering via publik nyckel och utan interaktiv session. Match block som är begränsat till det kontot håller behörigheten liten, och den privata nyckeln stannar på enheten där den hör hemma.

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 är den intressanta raden. Den nekar shell- och undersystemssessioner medan den fortfarande tillåter den vidarebefordran enheten behöver, så en stulen nyckel kan inte göras om till en interaktiv inloggning. PermitListen fäster lyssnarens adress och port på hubsidan, och GatewayPorts no håller den på loopback i stället för att öppna den mot nätverket hubben står på.

Testa den effektiva konfigurationen innan du laddar om, och håll en andra session öppen medan du gör det. Match block som av misstag gäller alla, eller ett stavfel i ett alternativnamn, är det klassiska sättet att låsa ut sig själv från lådan du härdar. Dumpa den körande konfigurationen och läs tillbaka alternativen i stället för att lita på filen du just skrev. Notera att alternativstödet skiljer sig mellan byggen, så en rad som accepteras i en nyare server kan helt enkelt ignoreras av en äldre.

Enhetssidan: vidarebefordran som misslyckas högljutt

Enheten öppnar anslutningen och begär lyssnaren. De två adresserna i argumentet -R betyder olika saker, och att läsa dem från vänster till höger är det snabbaste sättet att komma ihåg vilken som är vilken.

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 vänstra paret är där hubben ska lyssna. Det högra paret är vad enheten ansluter till när en förfrågan kommer, löst från enhetens egen sida. Att byta dem ger en tunnel som kommer upp rent och vidarebefordrar till fel ställe, vilket är värre än ett misslyckande.

ExitOnForwardFailure=yes får kommandot att avslutas när den begärda lyssnaren inte kan upprättas, så en omstartsslinga berättar sanningen i stället för att lämna en halvfungerande session. Den säger ingenting om huruvida den lokala SSH-tjänsten är frisk senare, så koppla den till en processhanterare och ett då och då riktigt anslutningstest.

Ersätt aldrig loopback-lyssnaradressen med ett jokertecken för att undvika ett extra hopp. Den enda ändringen är skillnaden mellan en administrationsväg och en port som är allmänt nåbar, och den sker oftast under felsökning och blir sedan kvar. Om en kollega inte når porten genom hubben, reparera hoppkonfigurationen i stället för att bredda bindningen. Loopback är hela säkerhetsargumentet för den här designen.

Administratörsåtkomst genom hubben

En administratör med ett vanligt konto på hubben kan hoppa genom den till den vidarebefordrade porten. Relay-kontot används inte för detta, och det är just poängen med att hålla dem åtskilda.

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

Verifiera enhetens värdnyckel under det alias du valde, eftersom den nyckeln identifierar enheten i kedjans ände och tunneln bara är transport. Inloggningen från ände till ände autentiserar fortfarande båda ändarna; en tunnel som slutar på en delad hubb gör den inte i sig själv till en betrodd väg.

Ta ägarskapet över livscykeln

Kör enhetskommandot under en processhanterare med exakt en aktiv instans och en omstartspolicy du har valt medvetet. Keepalive-alternativen upptäcker en död motpart; de återupplivar inte en process som har avslutats.

Skriv sedan avvecklingsproceduren. Varje enhet får sin egen lyssnare och sin egen nyckel, så avveckling innebär att återkalla det kontot och ta bort den nyckeln, inte att rotera en hemlighet som hela flottan delar.

Till sist, kom ihåg vad loopback ger dig. Det begränsar nätverksexponeringen och gör ingenting åt andra lokala användare på en delad hubb, så hubbens egen åtkomstpolicy måste fortfarande vara korrekt. sshd_config-referens dokumenterar var och en av de alternativ som används ovan, och det är värt att läsa vidarebefordringsavsnitten i sin helhet innan du utökar något av dem.