Med autorisert SSH-tilgang til en server kan OpenSSH opprette en SOCKS-lytter på datamaskinen din. SSH-forbindelsen bærer den videresendte trafikken, og den eksterne serveren oppretter målforbindelsen.

En lytter bare på loopback

ssh -N -T -o ControlPath=none -o ForkAfterAuthentication=no -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]

Bytt konto og vertsnavn. SSH-serveren må tillate videresending; administratoren kan begrense videresending og mål uavhengig av kontoinnlogging.

-D oppretter dynamisk videresending, og den eksplisitte loopbackadressen begrenser lytteren til denne maskinen. -N utelater en fjernkommando; -T utelater en pseudoterminal. ControlPath=none unngår en eksisterende delingsmaster, mens ForkAfterAuthentication=no holder dette kallet i forgrunnen.

Hold prosessen kjørende mens du bruker proxien. Hvis port 1080 er opptatt, velg en annen ledig høy port og oppdater klienten. ExitOnForwardFailure=yes får SSH til å avslutte hvis lytteren ikke kan opprettes.

Bruke SOCKS-endepunktet

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' --connect-timeout 5 --max-time 15 https://example.com/

Denne forespørselen delegerer håndtering av målnavnet gjennom SOCKS5. Andre programmer trenger egen SOCKS-konfigurasjon; et HTTP-proxyfelt kan ikke snakke SOCKS med denne lytteren.

Slik sjekker du hvilken prosess som eier porten:

ss -ltnp 'sport = :1080'

Den tiltenkte SSH-prosessen bør eie en loopbacklytter. En forespørsel gjennom den sjekker om den eksterne serveren også kan nå målet. Bruk et kontrollert mål når du må undersøke den observerte utgangen.

Øktens levetid

Ctrl-C lukker SSH-prosessen, lytteren og de videresendte forbindelsene. En brutt SSH-forbindelse gjør også proxien utilgjengelig.

ExitOnForwardFailure kontrollerer oppsettet. Det avslutter ikke SSH hver gang en senere målforbindelse feiler, så diagnostiser økten, den lokale porten og målforespørselen separat.

Relaterte artikler