CODEWITHSUNDEEP
linuxgitshellsshportforwarding
THG
THG

Reputation: 322

How to ssh forwarding with AllowTcpForwarding set to no?

There is some development that needs to get done on some remote box. Fortunately, I have shell access, but I need to go through a gateway that has AllowTcpForwarding set to false.

I took a peak at the docs and it says:

AllowTcpForwarding Specifies whether TCP forwarding is permitted. The default is ''yes''. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.

How would I go about installing (or building) my own forwarder? My goal here is to setup a remote interpreter using Pycharm via SSH and binding it to some local port, that data fed through ssh, that through the gateway, and then to the development box where the code is actually run.

I know I can ssh to my remote box by doing:

ssh -t user1@gateway ssh user2@devbox

But obviously this option isn't available in pycharm. I'll have to be able to open some local port such that

ssh -p 12345 localhost
(or variant)

will connect me to user2@devbox. This will allow me to configure the remote interpreter to use port 12345 on localhost to connect to the remote box.

Upvotes: 3

Views: 6088

Answers (2)

salva
salva

Reputation: 10242

There may be some program installed on the gateway you could use to forward stdio to a remote network port. For instance, look for corkscrew, netcat, nc, socat or proxytunnel.

Then if Perl is available on the gateway, you can use the one-liner available from here that I wrote some time ago to solve that same problem (the code is explained here).

Finally, you may also be able to run a SSH connection to the target machine using the ProxyCommand setting or some equivalent setting used by PyCharm.

Upvotes: 0

Kenster
Kenster

Reputation: 25438

If you have a legitimate need to tunnel connections through this gateway server, you should try talking to the gateway administrator to find an acceptable way to do your work. Finding a way to work around the server configuration won't alter the fact that you may be violating a policy that you're expected to follow. Having said that:

An SSH connection between a client and server supports multiple independent data streams, called channels. Port forwarding uses a channel type called "direct-tcpip". a Port forwarding operation has four parts:

  1. The ssh client (which is connected to an ssh server) binds to a TCP port and listen for connections.
  2. When something connects to the port which the client is listening to, the client sends a request to the server to open a "direct-tcpip" channel. The request from the client specifies the host and port that the channel should connect to.
  3. The ssh server on the remote system makes a TCP connection to the specified host and port.
  4. The ssh client relays data between the direct-tcpip channel and the local TCP connection.
  5. The ssh server relays data between the direct-tcpip channel and the remote TCP connection.

If the server has been configured not to permit TCP forwarding, then it will respond with an error to any direct-tcpip channel requests from the client. To work around that, as implied by the SSH documentation, the client needs to pass these forward requests through some other channel type which the client is permitted to open, and it needs to run some process on the remote system which performs steps 3 and 5 above--steps that would normally be done by the remote ssh server.

I don't know of any off-the-shelf solution for this. The scope of work here is:

  1. Develop a program that you can install on the gateway to perform the remote portion of a forwarding operation. The program would have to be able to make a TCP connection to the target host and port and then relay data between the TCP connection and the SSH connection.

  2. Develop a custom ssh client that can perform the local parts of a forward operation. It would need to bind to a local TCP port and listen for connections. When something connects, the client would have to open a channel to the server, invoke the remote program to connect to the tunnel target, and then relay data between the TCP connection and the ssh channel.

A plausible approach would be for the custom ssh client to open an "exec" or "shell" channel for each forwarded connection, and then invoke a program like netcat on the remote system. Netcat would need to connect to the target of the forward operation and then relay data between its standard input/output and the forward target. If you can't install netcat on the gateway, you could write a custom program for the purpose using perl, python, java, C, or any other language which is available on the gateway and which permits opening TCP connections.

Upvotes: 2

Related Questions