Menu
Scenario:
Many embedded devices (running Linux) out in the fields, behind routers so NAT'd and we can't make connections to them.
We need for a support person to be able to initiate a terminal/shell session on any of the devices.
Their local terminal will also be NAT'd behind a corporate firewall, so we need some central "meeting point" that both they and the device can connect to.
If necessary, we could require the support person to log into some sort of terminal server, but I'd prefer a solution that just popped up a terminal window on their desktop.
We can (through other means) tell the device to execute some arbitary script or application to start up the session.
Without the NAT, it's just SSH to the device and away we go. But what are my options in this NAT'd environment?
We're OK to develop code at either end or at the meeting point server if required, but obviously if there are apps out there so we don't have to write stuff, even better.
Pointers to other questions I may have missed (although I have looked) or to applications that I should consider for the central "meeting point" server welcomed
416
The answer lies in reverse SSH tunneling. What Is Reverse SSH Tunneling? Reverse SSH tunneling allows you to use that established connection to set up a new connection from your local computer back to the remote computer.
Using socat to get a reverse shell. Socat is also a popular utility/program other than netcat but usually not installed by default on most linux servers. If the target server has socat installed, you can use the following commands and get a tty shell directly without needing to upgrade it.
SSH will already be installed on your Linux computer, but you may need to start the SSH daemon (sshd) if the local computer has never accepted SSH connections before. To have the SSH daemon start each time you reboot your computer, use this command: On the remote computer, we use the following command.
Encrypted reverse shell connection might help manual/automatic detection by a network security monitoring tools on the target network harder and sometimes could even bypass the IDS. In order to use SSL in your reverse shell, first you need to generate a SSL certificate for the tunnel.
How about simply setting up an ssh server that is reachable by both the device and the support user, and have the device set up a reverse tunnel (using remote port forwarding)?
ssh -R 10022:localhost:22 device@server
Then the support personnel can simply connect to the server and log on using
ssh -p 10022 localhost
Of course there are several security aspects that need to be accounted for here, depending on what kind of information the devices hold/have access to and how the support organization is set up.
146
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
