I need help understanding the security implications of having an outgoing ssh tunnel in my system (what is the risk and could it be a security hole?).

I am using the following command to forward port 8080 in an internal system to 8080 in a remote host. I want to be able to forward traffic going to localhost:8080 to the remote host at port 8080.

ssh -f -N -L 8080:<remote_ip>:8080 user@<bastion_host>

This is a diagram of what I'm doing:

 ------------        ---------          ------------------
| remote:8080| <--- | bastion | <----- |internal host:8080|
 ------------        ---------          ------------------

These are my questions:

  1. Would it be possible for a potential attacker in the remote system to leverage an exploit that uses the port forwarding tunnel I have in place to get access to the internal host?
  2. Since this is a TCP connection, is there a socket going back to the internal host that an attacker could use?

I just want to know if this is at all possible or if there are safeguards in ssh to protect against this.


  • There's not much that UNIX/Linux-specific here; have you considered asking on the Security Stack?
    – Jeff Schaller
    Jul 10, 2019 at 14:39
  • @muru I'm more concerns about wether or not there are any connections going from remote to internal. In this case internal is a protected trusted environment. I'm just worried about wether or not I am opening up a hole in this trusted environment by having this tunnel in place.
    – Lynx
    Jul 10, 2019 at 15:01

1 Answer 1

  1. Yes, it is possible. For example, an attacker might be able to control the listening port 8080 on the remote host, and return data to whatever program is connecting from the internal hosts which causes that program to fail in a way which can be exploited. This is true of any network connection.

    Note that the network connection only exists when the internal host connects to the listening port exposed by the SSH client. There isn’t a port open permanently on the remote host leading back to the internal host. Also, the SSH server on the bastion host isn’t exposed to the remote host.

  2. No, there is no socket going back. An attacker would have to “hitch a ride” on a TCP session opened on behalf of the internal host, and (exploits aside) such a ride would be limited to the scope of the TCP session; it couldn’t reach out to other ports on the internal host or the bastion host.

You can make your connection less dependent on local configuration variations by making its local bind address explicit:

ssh -f -N -L localhost:8080:<remote_ip>:8080 user@<bastion_host>

This ensures that the port listening on the internal host is bound to localhost, and therefore only accessible to programs running on the internal host itself. (It will be accessible to all users on that host.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .