Обрнути 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]

Проверите кључ домаћина уређаја под изабраним псеудонимом, јер тај кључ идентификује уређај на крају ланца, а тунел је само транспорт. Пријава од краја до краја и даље аутентификује оба краја; тунел који се завршава на заједничком чворишту не чини га самим тим поузданим путем.

Преузмите животни циклус

Покрените команду уређаја под менаџером процеса са тачно једном активном инстанцом и политиком поновног покретања коју сте свесно изабрали. Опције keepalive откривају мртвог партнера; оне не оживљавају процес који је изашао.

Затим напишите процедуру за повлачење. Сваки уређај добија сопственог слушаоца и сопствени кључ, па повлачење значи опозив тог налога и уклањање тог кључа, а не ротирање тајне заједничке целој флоти.

На крају, сетите се шта вам loopback даје. Он ограничава мрежну изложеност и не чини ништа у вези са другим локалним корисницима на заједничком чворишту, па политика приступа самог чворишта и даље мора да буде исправна. Референца за sshd_config документује сваку од горе коришћених опција, и вреди у целини прочитати одељке о прослеђивању пре него што било коју од њих проширите.

Повезани чланци