SSH i kundërt për një pajisje: dëgjues loopback apo VPN e rrugëzuar?

Pajisja juaj qëndron pas NAT-it të operatorit, mund të hapë lidhje dalëse dhe drejton një server SSH të cilin askush nuk mund ta arrijë. Kërkesa që vjen zakonisht formulohet si "jepi një VPN", që është një përgjigje mes disave. Përpara se ta pranoni, vendosni nëse ju nevojitet një port TCP administrativ apo një rrugë e rrugëzuar drejt një nënrrjete të tërë, sepse ato janë projekte të ndryshme me ekspozim të ndryshëm.

Një tunel i kundërt i përgjigjet mirë versionit të ngushtë. Pajisja telefonon hub-in tuaj, i kërkon hub-it të dëgjojë në një port loopback dhe e përcjell atë port përsëri te shërbimi i vet SSH. Më pas administratorët arrijnë te dëgjuesi përmes hub-it, jo përmes internetit publik.

Tre kushte që vendosin zgjedhjen

Shkruajini ato para çdo konfigurimi. Ato janë kufiri midis një hyrjeje të kufizuar administrimi dhe një zgjerimi të rrjetit, dhe ngatërrimi i tyre është mënyra se si një tunel me pesë rreshta bëhet një rrjet i sheshtë pa pronar.

Rreshti i tretë është ai për të cilin njerëzit debatojnë. Një tunel drejt portës SSH të një pajisjeje nuk i vendos fqinjët e saj në rrjetin tuaj dhe nuk duhet të duket sikur e bën këtë përmes një zinxhiri përcjelljesh të mëtejshme. Nëse kërkesa është vërtet LAN-i, thuajeni dhe projektroni atë në vend të kësaj.

Ana e hub-it: një llogari rele e kufizuar

Jepini çdo pajisjeje llogarinë e vet rele me vërtetim me çelës publik dhe pa sesion interaktiv. Match blloku i kufizuar në atë llogari e mban lejen të vogël, dhe çelësi privat mbetet në pajisjen ku i takon.

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 është rreshti interesant. Ai refuzon sesionet e guaskës dhe të nënsistemeve, ndërsa lejon ende përcjelljen që pajisja ka nevojë, kështu që një çelës i vjedhur nuk mund të kthehet në një hyrje interaktive. PermitListen fikson adresën dhe portën e dëgjuesit në anën e hub-it, dhe GatewayPorts no e mban në loopback në vend që ta hapë për rrjetin ku ndodhet hub-i.

Testoni konfigurimin efektiv përpara ringarkimit dhe mbani një sesion të dytë të hapur ndërsa e bëni këtë. Match blloku që zbatohet aksidentalisht për të gjithë, ose një gabim shtypi në emrin e një opsioni, është mënyra klasike për të mbyllur veten jashtë kutisë që po forconi. Shkarkoni konfigurimin në punë dhe rilexoni opsionet në vend që t'i besoni skedarit që sapo shkruat. Vini re se mbështetja e opsioneve ndryshon midis ndërtimeve, kështu që një rresht i pranuar në një server më të ri mund të injorohet thjesht nga një më i vjetër.

Ana e pajisjes: përcjellje që dështon me zë

Pajisja hap lidhjen dhe kërkon dëgjuesin. Dy adresat në argumentin -R kanë kuptime të ndryshme, dhe leximi i tyre nga e majta në të djathtë është mënyra më e shpejtë për të mbajtur mend cila është cila.

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

Çifti i majtë është vendi ku hub-i duhet të dëgjojë. Çifti i djathtë është ajo me të cilën pajisja lidhet kur vjen një kërkesë, e zgjidhur nga ana e vetë pajisjes. Ndërrimi i tyre prodhon një tunel që ngrihet pastër dhe përcjell në vendin e gabuar, gjë që është më keq se një dështim.

ExitOnForwardFailure=yes e bën komandën të dalë kur dëgjuesi i kërkuar nuk mund të vendoset, kështu që një lak rinisjeje ju thotë të vërtetën në vend që të lërë një sesion gjysmëfunksional. Nuk thotë asgjë për atë nëse shërbimi lokal SSH është i shëndetshëm më vonë, prandaj kombinoni atë me një menaxher procesesh dhe një provë të vërtetë lidhjeje herë pas here.

Kurrë mos e zëvendësoni adresën e dëgjimit loopback me një kartë të egër për të shmangur një kërcim shtesë. Ai ndryshim i vetëm është dallimi midis një rruge administrimi dhe një porte të arritshme publikisht, dhe zakonisht ndodh gjatë korrigjimit dhe pastaj mbetet. Nëse një koleg nuk e arrin portën përmes hub-it, rregulloni konfigurimin e kërcimit në vend që të zgjeroni lidhjen. Loopback është i gjithë argumenti i sigurisë i këtij dizajni.

Qasja e administratorit përmes hub-it

Një administrator me një llogari të zakonshme në hub mund të kërcejë përmes tij te porta e përcjellë. Llogaria rele nuk përdoret për këtë, dhe pikërisht ky është qëllimi i mbajtjes së tyre të ndara.

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

Verifikoni çelësin e hostit të pajisjes nën aliasin që zgjodhët, sepse ai çelës identifikon pajisjen në fund të zinxhirit dhe tuneli është vetëm transport. Hyrja nga fundi në fund vazhdon të vërtetojë të dy skajet; një tunel që përfundon në një hub të përbashkët nuk e bën atë vetvetiu një rrugë të besuar.

Merrni pronësinë e ciklit të jetës

Drejtoni komandën e pajisjes nën një menaxher procesesh me saktësisht një shembull aktiv dhe një politikë rinisjeje që e zgjodhët me qëllim. Opsionet keepalive zbulojnë një partner të vdekur; ato nuk e ringjallin një proces që doli.

Pastaj shkruani procedurën e tërheqjes. Çdo pajisje merr dëgjuesin e vet dhe çelësin e vet, kështu që çaktivizimi nënkupton revokimin e asaj llogarie dhe heqjen e atij çelësi, jo rrotullimin e një sekreti të përbashkët për të gjithë flotën.

Së fundi, mbani mend çfarë ju jep loopback. Ai kufizon ekspozimin ndaj rrjetit dhe nuk bën asgjë për përdoruesit e tjerë lokalë në një hub të përbashkët, prandaj politika e qasjes e vetë hub-it duhet të jetë ende e saktë. Referenca e sshd_config dokumenton secilin nga opsionet e përdorura më sipër, dhe ia vlen të lexohen plotësisht seksionet e përcjelljes përpara se të zgjeroni ndonjë prej tyre.