SSH
Pivoting Using SSH
Last updated
Pivoting Using SSH
Last updated
The following are helpful options for creating port forwarding tunnels.
Option | Description |
---|---|
To forward traffic to an internal server via a reachable server
Now curl localhost:$LPORT
will fetch whatever is hosted on $RPORT
which is only accessible from the "reachable server".
To create a remote port forward, pass the -R
option to the ssh client:
The options used are as follows:
[REMOTE:]REMOTE_PORT
- The IP and the port number on the remote SSH server. An empty REMOTE means that the remote SSH server will bind on all interfaces.
DESTINATION:DESTINATION_PORT
- The IP or hostname and the port of the destination machine.
[USER@]SERVER_IP
- The remote SSH user and server IP address.
Remote port forwarding is mostly used to give access to an internal service to someone from the outside.
This will open $RPORT
on the attacker system and tunnel any traffic back to the reachable system.
On your attack system, create a new user account that has no shell to be used solely for receiving the remote port forward.
-L 9999:host2:80
Means bind to localhost:9999 and any packet sent to localhost:9999 forward it to host2:80
-R 9999:localhost:9999
Means any packet received by host1:9999 forward it back to localhost:9999
One way to make a tunnel so you can access the application on host2 directly from localhost:9999
To create a dynamic port forward (SOCKS proxy) pass the -D
option to the ssh client:
The options used are as follows:
[LOCAL_IP:]LOCAL_PORT
- The local machine IP address and port number. When LOCAL_IP is omitted, the ssh client binds on localhost.
[USER@]SERVER_IP
- The remote SSH user and server IP address.
A typical example of a dynamic port forwarding is to tunnel the web browser traffic through an SSH server.
To send traffic bound for any remote port through $LPORT
:
Now you can configure proxychains to send all (TCP) traffic through this as a Socks5 proxy.
-J
) to tunnel traffic through one host to anotherThese hops can be chained by using a comma (,
) to separate them (no space!). This also works with SCP to pull or push files through multiple hops.
You can also combine this with Dynamic port forwarding to make your socks proxy reach the remote internal system.
If you want to use a single ssh command to go from your PC to any of the hosts, you can use the ~/.ssh/config
configuration file which contains the details of each host and all identities needed to access each host from your system. The ProxyJump
keyword is used to specify an intermediate host that is needed to arrive at the target host.
From your computer, you can test each jump individually, i.e.
Another cool thing about the ~/.ssh/config
file is that this will also enable sftp file transfers via any series of hops, e.g.
-o
).The SSH Config File takes the following structure:
The contents of the SSH client config file is organized into stanzas (sections). Each stanza starts with the Host directive and contains specific SSH options used when establishing a connection with the remote SSH server.
Indentation is not required but is recommended since it makes the file easier to read.
The Host
directive can contain one pattern or a whitespace-separated list of patterns. Each pattern can contain zero or more non-whitespace character or one of the following pattern specifiers:
*
- Matches zero or more characters. For example, Host * matches all hosts, while 192.168.0.*
matches hosts in the 192.168.0.0/24 subnet.
?
- Matches exactly one character. The pattern, Host 10.10.0.? matches all hosts in 10.10.0.[0-9]
range.
!
- When used at the start of a pattern, it negates the match. For example, Host 10.10.0.* !10.10.0.5
matches any host in the 10.10.0.0/24 subnet except 10.10.0.5.
The SSH client reads the configuration file stanza by stanza, and if more than one patterns match, the options from the first matching stanza take precedence. Therefore, more host-specific declarations should be given at the beginning of the file, and more general overrides at the end of the file. You can find a full list of available SSH options by typing man ssh_config
in your terminal.
The SSH config file is also read by other programs such as SCP , SFTP , and rsync.
The SSH client reads its configuration in the following precedence order:
Options specified from the command line.
Options defined in the ~/.ssh/config
.
Options defined in the /etc/ssh/ssh_config
.
If you want to override a single option, you can specify it on the command line. For example, if you have the following definition:
and you want to use all other options but to connect as user root instead of john simply specify the user on the command line:
The -F (configfile)
option allows you to specify an alternative per-user configuration file.
To tell the ssh client to ignore all of the options specified in the ssh configuration file, use:
Add SSH key to an authorized_keys
file remotely using the ssh-copy-id
command.
setup proxychains with socks5 on 127.0.0.1:1080
Or set up socks5 proxy on firefox
For nmap use
-Pn -sT
or use tcp scanner in msf
First, SSH to your Kali from target machine
On Kali:
https://thegreycorner.com/2021/12/15/hackthebox_dante-review.html
Use the ssh escape sequence (which by default is <enter>
, then ~C
or shift-~
then shift-c
.) to access the ssh command line and create them as needed. If you’re not familiar with the ssh escape sequence, when the appropriate key combination is pressed at the regular ssh command prompt as the next keypress after Enter it drops you to a special prompt like so:
At this prompt, you gain the ability to enable a number of ssh options without having to enable them from the command line when establishing a new session. You can, for example, create a local port forward from port 8888 to the remote host and port 172.16.1.1:8000 in the current session like so:
Begin on the Attack machine by creating an SSH port forward. Send TCP port 6666 on localhost to TCP 9999 on the remote pivot server:
Then on the Pivot Server create a fifo file for netcat to talk to:
On the Attack machine do similar:
Now tools that use UDP (such as nmap UDP scans or snmp_check) can communicate through the tunnel!
-N
Makes SSH not execute any commands (such as creating a shell)
-T
Prevents a pseudo terminal from being allocated for the connection; however, commands can still be issued
-f
Forks the SSH client process into the background right after authentication; keeps the tunnel from blocking continued use of the current terminal