Omgekeerde SSH voor één apparaat: loopback-listener of gerouteerde VPN?

Je apparaat staat achter de NAT van een provider, het kan uitgaande verbindingen openen en het draait een SSH-server die niemand kan bereiken. Het verzoek dat binnenkomt wordt meestal geformuleerd als "geef het een VPN", wat één antwoord uit meerdere is. Voordat je het accepteert, beslis je of je één administratieve TCP-poort nodig hebt of een gerouteerd pad naar een heel subnet, want dat zijn verschillende projecten met verschillende blootstelling.

Een omgekeerde tunnel beantwoordt de smalle versie goed. Het apparaat belt je hub, vraagt de hub op een loopback-poort te luisteren en stuurt die poort terug naar zijn eigen SSH-dienst. Daarna bereiken beheerders de listener via de hub, niet via het openbare internet.

Drie voorwaarden die de keuze beslechten

Schrijf ze op vóór elke configuratie. Ze zijn de grens tussen een begrensde beheertoegang en een netwerkuitbreiding, en ze door elkaar halen is hoe een tunnel van vijf regels een eigenaarloos plat netwerk wordt.

De derde rij is degene waarover mensen discussiëren. Een tunnel naar de SSH-poort van een apparaat zet zijn buren niet op jouw netwerk, en het mag niet lijken alsof dat via een keten van verdere doorsturingen gebeurt. Als de eis echt het LAN is, zeg dat dan en ontwerp dat in plaats daarvan.

Hub-zijde: een begrensd relay-account

Geef elk apparaat zijn eigen relay-account met authenticatie via openbare sleutel en zonder interactieve sessie. Match blok dat tot dat account beperkt is, houdt de toestemming klein, en de privésleutel blijft op het apparaat waar hij 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 de interessante regel. Het weigert shell- en subsysteemsessies terwijl het de doorsturing toestaat die het apparaat nodig heeft, zodat een gestolen sleutel niet in een interactieve login kan veranderen. PermitListen legt het adres en de poort van de listener aan de hub-zijde vast, en GatewayPorts no houdt hem op loopback in plaats van hem te openen naar het netwerk waarop de hub staat.

Test de effectieve configuratie voordat je herlaadt, en houd tijdens het testen een tweede sessie open. Match blok dat per ongeluk voor iedereen geldt, of een typefout in een optienaam, is de klassieke manier om jezelf buiten te sluiten van de machine die je hardt. Dump de actieve configuratie en lees de opties terug in plaats van het bestand te vertrouwen dat je net hebt geschreven. Merk op dat optieondersteuning verschilt tussen builds, zodat een geaccepteerde regel in een nieuwere server eenvoudig door een oudere genegeerd kan worden.

Apparaatzijde: doorsturing die luid mislukt

Het apparaat opent de verbinding en vraagt de listener aan. De twee adressen in het -R argument betekenen verschillende dingen, en ze van links naar rechts lezen is de snelste manier om te onthouden welke welke 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]

Het linkerpaar is waar de hub moet luisteren. Het rechterpaar is waar het apparaat mee verbindt als er een verzoek komt, opgelost vanaf de eigen zijde van het apparaat. Ze omwisselen levert een tunnel op die schoon omhoog komt en naar de verkeerde plek doorstuurt, wat erger is dan een fout.

ExitOnForwardFailure=yes laat het commando stoppen wanneer de gevraagde listener niet kan worden opgezet, zodat een herstartlus je de waarheid vertelt in plaats van een halfwerkende sessie achter te laten. Het zegt niets over of de lokale SSH-dienst later gezond is, dus combineer het met een procesmanager en een af en toe echte verbindingstest.

Vervang het loopback-luisteradres nooit door een jokerteken om een extra sprong te vermijden. Die ene wijziging is het verschil tussen een beheerpad en een openbaar bereikbare poort, en het gebeurt meestal tijdens het debuggen en blijft dan staan. Als een collega de poort niet via de hub bereikt, repareer dan de jump-configuratie in plaats van de binding te verbreden. Loopback is het hele beveiligingsargument van dit ontwerp.

Beheerderstoegang via de hub

Een beheerder met een gewoon account op de hub kan erdoorheen naar de doorgestuurde poort springen. Het relay-account wordt hiervoor niet gebruikt, en dat is precies het punt om ze gescheiden te houden.

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

Controleer de hostsleutel van het apparaat onder de alias die je hebt gekozen, want die sleutel identificeert het apparaat aan het einde van de keten en de tunnel is alleen transport. De end-to-end-login authenticeert nog steeds beide uiteinden; een tunnel die op een gedeelde hub eindigt, maakt het niet vanzelf een vertrouwd pad.

Neem eigenaarschap van de levenscyclus

Draai het apparaatcommando onder een procesmanager met precies één actieve instantie en een herstartbeleid dat je bewust hebt gekozen. De keepalive-opties detecteren een dode partner; ze wekken geen proces tot leven dat is gestopt.

Schrijf daarna de uitfaseringprocedure. Elk apparaat krijgt zijn eigen listener en zijn eigen sleutel, dus buiten gebruik stellen betekent dat account intrekken en die sleutel verwijderen, niet een geheim rouleren dat de hele vloot deelt.

Onthoud ten slotte wat loopback je oplevert. Het beperkt de netwerkblootstelling en doet niets aan andere lokale gebruikers op een gedeelde hub, dus het toegangsbeleid van de hub zelf moet nog steeds kloppen. sshd_config-referentie documenteert elk van de hierboven gebruikte opties, en het is de moeite waard de doorsturingssecties volledig te lezen voordat je een ervan verbreedt.