Wêrom't in omkearde SSH-proxy-harker allinnich op de tsjinner berikber is
Kontrolearje it bindadres fan 'e fiere harker en de GatewayPorts-modus foardat jo it proxyprotokol of de oanmeldgegevens feroarje.
In fiere trochstjoering kin fan 'e SSH-tsjinner ôf wurkje mar ferbiningen fan in oare masine wegerje, om't er allinnich op loopback harket. Kontrolearje earst it werklike harkadres.
Oan tsjinnerkant GatewayPorts | Bind fan fiere trochstjoering |
|---|---|
no, de standert | Beheint harkers ta loopback |
yes | Twingt wildcard-bind |
clientspecified | Lit de klant in bepaald bindadres oanfreegje |
Foar in harker bedoeld foar ien kontrolearre ynterface kin de tsjinner brûke:
GatewayPorts clientspecifiedDe klant freget dan in passend adres oan yn syn -R-spesifikaasje. Dat adres moat op 'e fiere masine bestean, en oare trochstjoeringsbeheiningen jilde noch. De -g oan klantkant is gjin útwikselbere kontrôle foar dizze rjochting.
Trije tastimmingen bliuwe skieden: SSH-autorisaasje om de trochstjoering te meitsjen, netwurktoegong ta syn harker en it eigen tagongsbelied fan 'e HTTP- of SOCKS-tsjinst. In SSH-oanmelding autentisearret de makker fan 'e tunnel; it autentisearret net elke lettere oanropper fan in dielde harker en foeget gjin SOCKS-wachtwurdútdaging ta.
As in fiere oanropper noch altyd net ferbine kin, kontrolearje dan it bindadres, de trochstjoeringsbeheiningen fan 'e tsjinner en it fjoermuorrepaad yn dy folchoarder. Sadree't TCP de harker berikt, is in mislearre proxy-hânskieding in letter probleem.