Provide SOCKS access through SSH dynamic forwarding

Needs: SSH forwarding allowed and clients that support SOCKS or compatible interception; DNS behavior must be chosen explicitly

Shell commands

# Baseline
ssh -N -D 127.0.0.1:1080 -p SSH_PORT USER@PIVOT \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3

Verify → Verify one application through the proxy, then check each client's actual proxy and DNS behavior.

If it fails → A working proxy does not make raw SYN/UDP scans viable. Use connect-based clients or a suitable routed tunnel. More detail ↓

If → then

A SOCKS listener or an SSH jump host is already available → Use ProxyChains, native SOCKS clients and SSH jump paths appropriately
Needs: Client/proxy transport compatibility, correct proxy configuration and controlled name resolution
An assigned host needs an initial service queue or full TCP coverage → Discover TCP ports with SYN or connect scans
Needs: SYN scanning needs raw-packet privileges; connect scanning needs OS TCP connections; specify selected versus full port coverage
An IP connection works while hostname/Kerberos access fails → Preserve DNS, Kerberos names and time across a pivot
Needs: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Provide SOCKS access through SSH dynamic forwarding

USE WHEN: Several internal TCP services need access through one SSH server
STARTING ACCESS: A pivot identity/process or reachable SSH service and a drawn source-to-destination path
RESULT: A client-side SOCKS proxy for selected destination connections

Recognize the clue

From accepted SSH and a mapped internal service set determine whether each required client can use a SOCKS TCP connection.

ssh -v -p SSH_PORT USER@PIVOT

SYNTHETIC EXAMPLE OUTPUT

SSH path: accepted
Needed destinations: several TCP services
Client proxy support: inspect

Means: Multiple client-selected TCP destinations suggest a dynamic SOCKS listener rather than many fixed forwards.

Confirm: Check SSH forwarding, listener bind, native/intercepted client support and DNS resolution location.

After validation: Proxy-aware clients reach the selected applications: choose dynamic SOCKS.
Ruled out in this context: The needed operation relies on raw/unsupported UDP traffic: reject ordinary TCP SOCKS for that operation.
Still inconclusive: A working SSH session without a proxy-aware test leaves application/proxy compatibility unknown.

Troubleshooting: A working proxy does not make raw SYN/UDP scans viable. Use connect-based clients or a suitable routed tunnel.

OpenSSH acts as a SOCKS4/5 server. The pivot makes destination connections selected by each SOCKS request.

Why it works

A SOCKS client requests each destination through the SSH server. Raw packets and arbitrary UDP are not automatically proxied by ordinary TCP SOCKS wrappers.

Worked example · hypothetical

Observation: multiple web/SMB services are reachable from the SSH server. Test: create the dynamic listener and send a proxy-aware HTTP request. Illustrative output: the internal page loads through SOCKS. Interpretation: use only compatible TCP clients and validate DNS separately.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗