Notes

An offensive security guide to SSH tunnels and proxies.
SSH Basics
A user can remotely connect to a host using SSH and typically get a shell prompt or interactive shell. The above can be used to execute commands. Both Windows and Linux deploy SSH servers, and both have a built-in SSH client. This post is based on references to OpenSSH, the most prevalent implementation of an SSH client / server.
Firewall
A SSH server must always include firewall rules that whitelist connections from a particular host since SSH enables remote control of hosts. In particular, this is true if the SSH server is accessible from the internet. Compromised infrastructure could be valuable to adversaries; giving them access would be a big failure.
An authentication procedure
Authentication for SSH connections requires only username and password. The user can also create a public and private key pair that can be used instead of a password in SSH. Asymmetric encryption is possible with these keys. Just like a secret, users should keep a safe note of their generated private key. Putting the generated public key into the SSH authorized keys file for the target host is the next step.
An attacker can access a server using a recovered private key just like a password. In order to fulfill this requirement, SSH keys should be encrypted with a password that acts as a second factor. To create a 4096-bit RSA key pair, use the ssh-keygen utility.
I've used ssh-keygen -t rsa -b 4096
By default, this will generate a private key named id rsa and a public key named id rsa.pub. When prompted, enter a password to encrypt the key. To prevent unauthorized access, the user must restrict access to the private key file. If file permissions are set so that others can view the file, the SSH client ignores the identity file and displays an error. In a Linux environment, the permissions for a file should be 600, so that the user can read and write it, but that the group and other users are not allowed access.
As each major section of this post builds on the previous one, it will also be broken down into numbered parts in an effort to increase understanding. In addition to the visual display of the network connectivity and identification of which hosts commands should be executed on, a visual image will be provided after each set of commands. LINUX1 is the operator's Linux workstation, and REDIR1 is a web-accessible server that's part of offensive operations infrastructure.
The following image illustrates how to use a SSH private key to connect to the server REDIR1 using the rastley user from LINUX1:

Install the SSH client on LINUX1
/ root / priv.key contains the user's identity file and private key.
SSH into REDIR1 as rastley and log in
Here is an illustration of opening an SSH connection from LINUX1 to REDIR1


SSL/SSH & Private Key
The forward tunnel to remote ports
Connect to a compromised port on a client host by using a redirector
Imagine that an operator compromises a host called PWNED1 running an SSH server during a breach assessment. A compromised host now needs to be accessed by SSH from the internet by the operator. A remote port forward is setup, aka a reverse tunnel, which connects PWNED1 to the operator's internet access server REDIR1. REDIR1 Once the tunnel is setup, the operator will be able to directly access the compromised server through the redirector.
Make use of the SSH client -R flag to build a Remote port forward tunnel from the compromised host. [Bind address:] Port:Host:Hostport is an argument. This bind address corresponds to the IP address of the interface where the tunnel should bind, or listen on, for the remote host. YSSL connects to SSH server address bind/hostname not SSH server address bind/hostname. The default OpenSSH connection uses the hosts loopback adapter IP address, 1270.01. In the SSH server / etc / ssh / sshd config file, the GatewayPorts option must be enabled if you want to use a different interface IP. As SSH Client as this option is enabled, and the bind address is null, 00.00, or a *, the network will bind to ALL interfaces. Tunnel now poses a problem as it can be connected to by anyone on the internet because tunnel is listening on a public IP address, helping it reach the internal compromised host. The tunnel will only bind to the loopback adapter if the GatewayPorts option is not enabled, and the bind address is blank. Operators are therefore urged to specify explicit bind addresses rather than assuming the SSH server configurations.
It might also refer to any IP address if modified in a hosts file, which is part of the computers directory. Therefore, operators are recommended to always explicitly use the address 1270.01 when networking. A loopback adapter is assumed to resolve to a DNS name instead.

On the bind address interface of the remote server, the port argument tells the tunnel what port to bind to. It is essential that the port be free and that the user account has the permissions to bind to the port; a port below 1024 is not acceptable
On the source host, this is the interface the tunnel will bind to where the command is executed, and from which the connection is initiated. It is best to explicitly specify 1270.01 as the loopback adapter as before.


Homepage: https://shellngn.com