Inversa SSH por unu aparato: loopback-auskultanto aŭ enkursigita VPN?

Via aparato sidas malantaŭ la NAT de la provizanto, ĝi povas malfermi elirajn konektojn, kaj ĝi funkciigas SSH-servilon, kiun neniu povas atingi. La peto, kiu alvenas, kutime formuliĝas kiel "donu al ĝi VPN", kio estas unu respondo inter pluraj. Antaŭ ol vi akceptos ĝin, decidu, ĉu vi bezonas unu administran TCP-pordon aŭ enkursigitan vojon al tuta subreto, ĉar tiuj estas malsamaj projektoj kun malsama elmetiĝo.

Inversa tunelo bone respondas al la mallarĝa versio. La aparato vokas vian hubon, petas la hubon aŭskulti sur loopback-pordo, kaj plusendas tiun pordon reen al sia propra SSH-servo. Poste administrantoj atingas la auskultanton tra la hubo, ne tra la publika interreto.

Tri kondiĉoj, kiuj decidas la elekton

Skribu ilin antaŭ ajna agordo. Ili estas la limo inter limigita administra eniro kaj reta etendo, kaj ilin konfuzi estas la maniero, kiel tunelo el kvin linioj fariĝas senposeda plata reto.

La tria vico estas tiu, pri kiu homoj disputas. Tunelo al la SSH-pordo de aparato ne metas ĝiajn najbarojn en vian reton, kaj oni ne devus igi ĝin aspekti tiel per ĉeno de pliaj plusendoj. Se la postulo vere estas la LAN, diru tion kaj projektadu ĝin anstataŭe.

Huba flanko: limigita relajsa konto

Donu al ĉiu aparato sian propran relajsan konton kun publikŝlosila aŭtentigo kaj sen interaga seanco. Match bloko limigita al tiu konto tenas la permeson malgranda, kaj la privata ŝlosilo restas sur la aparato, kie ĝi apartenas.

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 estas la interesa linio. Ĝi rifuzas ŝelajn kaj subsistemajn seancojn dum ĝi ankoraŭ permesas la plusendadon, kiun la aparato bezonas, do ŝtelita ŝlosilo ne povas esti ŝanĝita en interagan ensaluton. PermitListen fiksas la adreson kaj pordon de la auskultanto ĉe la huba flanko, kaj GatewayPorts no tenas ĝin sur loopback anstataŭ malfermi ĝin al la reto, en kiu la hubo troviĝas.

Testu la efektivan agordon antaŭ la reŝargo, kaj tenu duan seancon malfermita dum vi faras tion. Match bloko, kiu hazarde aplikiĝas al ĉiuj, aŭ tajperaro en opcia nomo, estas la klasika maniero ŝlosi vin ekster la maŝino, kiun vi malmoligas. Eligu la kurantan agordon kaj relegu la opciojn anstataŭ fidi la dosieron, kiun vi ĵus skribis. Notu, ke opcia subteno malsamas inter versioj, do linio akceptita de pli nova servilo povas simple esti ignorata de pli malnova.

Aparata flanko: plusendado, kiu malsukcesas laŭte

La aparato malfermas la konekton kaj petas la auskultanton. La du adresoj en la -R argumento signifas malsamajn aferojn, kaj legi ilin de maldekstre dekstren estas la plej rapida maniero memori, kiu estas kiu.

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

La maldekstra paro estas, kie la hubo devus aŭskulti. La dekstra paro estas, al kio la aparato konektiĝas, kiam peto alvenas, solvita de la propra flanko de la aparato. Interŝanĝi ilin produktas tunelon, kiu leviĝas pure kaj plusendas al la malĝusta loko, kio estas pli malbona ol malsukceso.

ExitOnForwardFailure=yes igas la komandon eliri, kiam la petita auskultanto ne povas esti starigita, do restartiga buklo diras al vi la veron anstataŭ lasi duonfunkciantan seancon. Ĝi diras nenion pri tio, ĉu la loka SSH-servo estas sana poste, do kunigu ĝin kun proceza administranto kaj okaza vera konekta testo.

Neniam anstataŭigu la loopback-auskultan adreson per ĵokera signo por eviti plian salton. Tiu sola ŝanĝo estas la diferenco inter administra vojo kaj publike atingebla pordo, kaj ĝi kutime okazas dum sencimigado kaj poste restas. Se kolego ne povas atingi la pordon tra la hubo, riparu la saltan agordon anstataŭ larĝigi la bindon. Loopback estas la tuta sekureca argumento de ĉi tiu dezajno.

Administranta aliro tra la hubo

Administranto kun ordinara konto sur la hubo povas salti tra ĝi al la plusendita pordo. La relajsa konto ne estas uzata por tio, kaj ĝuste tio estas la senco teni ilin apartaj.

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

Kontrolu la gastigan ŝlosilon de la aparato sub la pseŭdonimo, kiun vi elektis, ĉar tiu ŝlosilo identigas la aparaton ĉe la fino de la ĉeno kaj la tunelo estas nur transporto. La finsuperfina ensaluto ankoraŭ aŭtentigas ambaŭ finojn; tunelo, kiu finiĝas sur komuna hubo, ne faras ĝin per si mem fidinda vojo.

Posedu la vivciklon

Rulu la aparatan komandon sub proceza administranto kun ĝuste unu aktiva kazo kaj restartiga politiko, kiun vi elektis konscie. La keepalive-opcioj detektas mortan partneron; ili ne revivigas procezon, kiu eliris.

Poste skribu la malmuntan proceduron. Ĉiu aparato ricevas sian propran auskultanton kaj sian propran ŝlosilon, do malmuntado signifas revoki tiun konton kaj forigi tiun ŝlosilon, ne rotacii sekreton komunan al la tuta floto.

Finfine memoru, kion loopback donas al vi. Ĝi limigas retan elmetiĝon kaj faras nenion pri aliaj lokaj uzantoj sur komuna hubo, do la propra alirpolitiko de la hubo ankoraŭ devas esti ĝusta. Referenco pri sshd_config dokumentas ĉiun el la supre uzitaj opcioj, kaj indas legi la plusendajn sekciojn plene antaŭ ol larĝigi iun ajn el ili.