Зваротны SSH для адной прылады: слухач на loopback ці маршрутызаваны VPN?

Адзін адміністрацыйны порт для прылады, якая можа толькі званіць вонкі. Тры ўмовы вырашаюць, ці дастаткова зваротнага тунеля, ці патрэбны сапраўдны маршрутызаваны шлях.

Ваша прылада знаходзіцца за NAT аператара, яна можа адкрываць зыходныя злучэнні і запускае SSH-сервер, да якога ніхто не дабярэцца. Запыт, які прыходзіць, звычайна гучыць як "дайце ёй VPN", і гэта адзін адказ з некалькіх. Перш чым пагадзіцца, вырашыце, ці патрэбны вам адзін адміністрацыйны TCP-порт, ці маршрутызаваны шлях да ўсёй падсеткі, бо гэта розныя праекты з розным уздзеяннем.

Зваротны тунель добра адказвае на вузкую версію. Прылада злучаецца з вашым хабом, просіць хаб слухаць на loopback-порце і перанакіроўвае гэты порт назад на ўласную службу SSH. Пасля адміністратары дабіраюцца да слухача праз хаб, а не праз публічны інтэрнэт.

Тры ўмовы, якія вызначаюць выбар

Запішыце іх да любой канфігурацыі. Яны — мяжа паміж абмежаваным адміністрацыйным уваходам і пашырэннем сеткі, і блытаніна паміж імі — гэта шлях, якім тунель з пяці радкоў ператвараецца ў безгаспадарную плоскую сетку.

ConditionReverse tunnel fitsSomething else is needed
How many services must be reachable?One, or a small fixed set on loopbackAnything that needs many ports or dynamic discovery
Who connects, and how are they authenticated?Named administrators with their own hub accountsThird parties, or anything needing per-flow audit you do not control
Does the device's own LAN need to be reachable?NoYes, so a routed VPN or a managed platform is the honest answer

Трэці радок — той, вакол якога людзі спрачаюцца. Тунель да SSH-порта прылады не ставіць яе суседзяў у вашу сетку, і не варта рабіць выгляд, што ставіць, праз ланцуг дадатковых перанакіраванняў. Калі патрабаванне сапраўды пра LAN, скажыце гэта і праектуйце менавіта яе.

Хаб: абмежаваны ўліковы запіс рэле

Дайце кожнай прыладзе ўласны ўліковы запіс рэле з аўтэнтыфікацыяй па публічным ключы і без інтэрактыўнай сесіі. Match блок, абмежаваны гэтым уліковым запісам, трымае дазвол невялікім, а прыватны ключ застаецца на прыладзе, дзе яму і месца.

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 — цікавы радок. Ён адмаўляе сесіі абалонкі і падсістэм, але дазваляе перанакіраванне, патрэбнае прыладзе, таму выкрадзены ключ нельга ператварыць у інтэрактыўны ўваход. PermitListen фіксуе адрас і порт слухача на баку хаба, а GatewayPorts no трымае яго на loopback, а не адкрывае для сеткі, у якой знаходзіцца хаб.

Праверце фактычную канфігурацыю перад перазагрузкай і трымайце другую сесію адкрытай, пакуль робіце гэта. Match блок, які выпадкова ўжываецца да ўсіх, або друкавальная памылка ў назве опцыі — класічны спосаб зачыніць сябе з той машыны, якую вы ўмацоўваеце. Выгрузіце працуючую канфігурацыю і перачытайце опцыі, а не давярайце толькі што запісанаму файлу. Заўважце, што падтрымка опцый адрозніваецца паміж зборкамі, таму прыняты радок у новым серверы можа проста ігнаравацца старым.

Бок прылады: перанакіраванне, якое гучна падае

Прылада адкрывае злучэнне і запытвае слухач. Два адрасы ў аргуменце -R азначаюць рознае, і чытанне іх злева направа — самы хуткі спосаб запомніць, які з іх які.

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

Левая пара — гэта дзе павінен слухаць хаб. Правая пара — гэта тое, да чаго прылада падключаецца, калі прыходзіць запыт, вырашанае з боку самой прылады. Калі памяняць іх месцамі, атрымаецца тунель, які ўздымаецца бясспрэчна і перанакіроўвае не туды, а гэта горш за правал.

ExitOnForwardFailure=yes прымушае каманду выходзіць, калі запытаны слухач не можа быць усталяваны, таму цыкл перазапуску паведамляе праўду, а не пакідае паўпрацуючую сесію. Ён нічога не кажа пра тое, ці здаровая лакальная служба SSH пазней, таму спалучыце яго з менеджарам працэсаў і час ад часу сапраўдным тэстам злучэння.

Ніколі не замяняйце адрас праслухоўвання loopback на шаблон, каб пазбегнуць лішняга пераходу. Гэта адзіная змена — розніца паміж адміністрацыйным шляхам і публічна дасяжным портам, і звычайна яна адбываецца падчас адладкі, а потым застаецца. Калі калега не можа дабрацца да порта праз хаб, выпраўце канфігурацыю пераходу, а не пашырайце прывязку. Loopback — гэта ўвесь аргумент бяспекі гэтага дызайну.

Доступ адміністратара праз хаб

Адміністратар са звычайным уліковым запісам на хабе можа перайсці праз яго да перанакіраванага порта. Уліковы запіс рэле для гэтага не выкарыстоўваецца, і менавіта ў гэтым сэнс трымаць іх асобна.

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

Праверце ключ хоста прылады пад выбраным псеўданімам, бо гэты ключ ідэнтыфікуе прыладу ў канцы ланцуга, а тунель — толькі транспарт. Уваход ад канца да канца па-ранейшаму аўтэнтыфікуе абодва бакі; тунель, што заканчваецца на агульным хабе, не робіць яго давераным шляхам сам па сабе.

Валодайце жыццёвым цыклам

Запускайце каманду прылады пад менеджарам працэсаў з роўна адным актыўным экзэмплярам і палітыкай перазапуску, якую вы абралі свядома. Опцыі захавання злучэння выяўляюць мёртвага партнёра; яны не ўваскрашаюць працэс, які выйшаў.

Затым напішыце працэдуру вываду з эксплуатацыі. Кожная прылада атрымлівае свой слухач і свой ключ, таму вывад азначае адкліканне гэтага запісу і выдаленне гэтага ключа, а не ратацыю агульнага для ўсіх сакрэту.

Нарэшце, успомніце, што дае вам loopback. Ён абмяжоўвае сеткавае ўздзеянне і нічога не робіць з іншымі лакальнымі карыстальнікамі на агульным хабе, таму ўласная палітыка доступу хаба ўсё яшчэ мусіць быць правільнай. Даведка sshd_config апісвае кожную з выкарыстаных вышэй опцый, і варта цалкам прачытаць раздзелы пра перанакіраванне, перш чым пашыраць любую з іх.

Падобныя артыкулы