Forward a selected service through an SSH client-side listener

Needs: Accepted SSH identity and forwarding policy; local listener availability and SSH-server-to-destination route

Run on Kali when Kali can SSH to the pivot

# Run on Kali when Kali can SSH to the pivot
ssh -N \
  -L 127.0.0.1:LOCAL_PORT:INTERNAL_HOST:INTERNAL_PORT \
  -p SSH_PORT USER@PIVOT \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3

# Use the listener as though it were the internal service
nc -nvz 127.0.0.1 LOCAL_PORT
curl -v http://127.0.0.1:LOCAL_PORT/

Add reliability and attributable failure to transport-only sessions

The SSH server/pivot resolves and connects to INTERNAL_HOST. Bind to 127.0.0.1 unless another authorized local host must use the forward; -g or a non-loopback bind expands exposure.

Add reliability and attributable failure to transport-only sessions:

# Add reliability and attributable failure to transport-only sessions
-N
-o ExitOnForwardFailure=yes
-o ServerAliveInterval=30
-o ServerAliveCountMax=3

Verify → Verify listening address plus the destination application's handshake and preserve correct hostname/SPN semantics when needed.

If it fails → Administrative-prohibited indicates SSH forwarding policy; address-in-use is a local bind problem; timeout can be the remote leg. More detail ↓

If → then

A MySQL-compatible service and valid application/database credentials → Use MySQL/MariaDB data and file primitives
Needs: Database authentication and exact schema/file privileges; secure_file_priv and server filesystem identity constrain file actions
SQL Server credentials or a Windows identity accepted by the database → Use SQL Server rights, impersonation and command facilities
Needs: Correct SQL versus Windows authentication; database role and configuration must permit the requested operation
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

Forward a selected service through an SSH client-side listener

USE WHEN: SSH reaches a server that can access the needed internal service
STARTING ACCESS: A pivot identity/process or reachable SSH service and a drawn source-to-destination path
RESULT: A client-side port carrying the chosen internal TCP service

Recognize the clue

Use accepted SSH and the SSH server's verified reachability to a selected internal/loopback service; identify where the local client needs its listener.

ssh -v -p SSH_PORT USER@PIVOT
ss -lnt

SYNTHETIC EXAMPLE OUTPUT

Assessment client -> SSH server: accepted
SSH server -> 127.0.0.1:INTERNAL_PORT: needed
Desired listener: assessment client

Means: Client-side listener plus server-side destination is the -L direction; destination loopback belongs to the SSH server.

Confirm: Verify forwarding policy, local bind and server-to-destination application access.

After validation: The permitted local forward delivers the service handshake: choose -L.
Ruled out in this context: The server cannot reach the selected destination: reject this topology regardless of valid SSH login.
Still inconclusive: SSH login alone leaves forwarding policy unknown.

Troubleshooting: Administrative-prohibited indicates SSH forwarding policy; address-in-use is a local bind problem; timeout can be the remote leg.

Run on Kali when Kali can SSH to the pivot:

Use the listener as though it were the internal service:

The SSH server/pivot resolves and connects to INTERNAL_HOST. Bind to 127.0.0.1 unless another authorized local host must use the forward; -g or a non-loopback bind expands exposure.

Add reliability and attributable failure to transport-only sessions:

ExitOnForwardFailure proves requested listening sockets were established. It does not prove the final destination is reachable through them.

Why it works

With -L the listener is on the SSH client and the remote destination is reached from the SSH server. localhost in the destination therefore means the server's loopback.

Worked example · hypothetical

Observation: a database listens only on the SSH server's loopback. Test: use the documented local forward to that loopback port. Illustrative output: the client-side database connection works. Interpretation: authenticate using database-specific credentials.

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

Study guide ↗Full procedure ↗Cheatsheet ↗