Bereik 'n bestaande HTTP- of SOCKS-proxy deur SSH
Bereik 'n afgeleë loopback HTTP- of SOCKS-proxy deur SSH sonder om sy luisteraar publiek bloot te stel.
As relay.example.net reeds SOCKS op sy eie 127.0.0.1:1080 bedryf, stuur toegang deur eerder as om daardie luisteraar publiek bloot te stel:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Eindpunt | Rol |
|---|---|
Skootrekenaar 127.0.0.1:1081 | Die SOCKS-adres wat in die skootrekenaar se toepassing opgestel moet word. |
Relay 127.0.0.1:1080 | Die bestaande proxy wat van die SSH-bedienerkant bereik word. |
Die plaaslike deurvoersintaksis ken die vaste bestemming aan die bedienerkant toe. 'n HTTP-proxy op die afgeleë loopback-poort 3128 of 'n intranet-eindpunt soos proxy.internal.example:8080 werk op dieselfde beginsel. Stel die kliënt vir daardie bestaande HTTP-protokol en rekening op; om dit deur SSH te dra, skep nie SOCKS of 'n TLS-geaktiveerde HTTPS-luisteraar nie.
Die bestaande diens kies steeds ondersteunde protokolweergawes, verifikasie, bestemmings en die finale uitgang. As 'n ander SSH-proses daardie afgeleë proxy geskep het, moet albei prosesse aan die lewe bly. 'n Skootrekenaar→relay→poortwag-roete laat die webwerf die laaste uitwaartse verbinding sien, nie 'n identiteit wat deur plaaslike poort 1081 toegeken is nie.
Hou die skootrekenaar se binding uitdruklik plaaslik. Wyder blootstelling verander wie die diens kan bereik, en SSH-aanmelding voeg nie 'n SOCKS-wagwoord by die luisteraar nie. Vir weiering, ondersoek die skootrekenaar-luisteraar, SSH-vervoer en die afgeleë proxy as afsonderlike stadiums.