<p>Assuming that the monitoring host is able to make <em>outbound</em> connections, you can solve this by having a <a href="https://en.wikipedia.org/wiki/Bastion_host" rel="nofollow noreferrer">bastion host</a> elsewhere which you can connect through. Obviously do make sure to clear this with your customer.</p>

<p>To do this, set up a server somewhere under your control. This might be a VPS with a generous traffic limit, or it might be a physical server under your control, or something else. Give it a stable DNS name, possibly on a one-per-customer basis, which maps to the IP address of the bastion host. Mind the possibility that you may need to renumber that host in the future, possibly without being able to access the monitoring host.</p>

<p>Now, configure the monitoring host (the one that you want to be able to ultimately connect to) to connect <em>out</em> to the bastion host to set up a SSH tunnel. This will probably include creating a non-privileged user account on the monitoring host to run the tunnelling SSH process, and protecting that appropriately. (Remember: this account won't be used for logging in to; it will only run a local, non-interactive SSH client process, and own the tunnel.) Also set up a non-privileged account on the bastion host, with only sufficient privileges to log in with SSH (not to a shell) and set up a SSH tunnel to the monitoring host.</p>

<p>With that in place, you can set up something like <code>autossh</code> on the monitoring host to maintain a connection to the bastion host to keep the tunnel alive. Add some decent logging on the bastion host, since on the monitoring host, the connection will almost certainly look like it originates from localhost.</p>

<p>When you need to connect to the monitoring host, first connect to the bastion host setting up a SSH tunnel to the bastion host's local port that forwards to the monitoring host; and then connect to the local port that maps to that tunnel. This will tunnel the SSH traffic <em>via</em> the bastion host, allowing your system to talk to the ultimate target host without requiring the host that is ultimately being connected to to be able to accept incoming connections.</p>

CC BY-SA 4.0
2018-11-28T13:21:13.223Z
2018-11-28T13:21:13.223Z
user
<p>Officially, you should ask those firewall admins to create you a VPN access on each router, optionally ask them to have only access to your server behind their firewall.</p>

<p>That will leave you a user account to manage your updates, while at the same time you will be covered legally: if a leak happens, or a security issue happen, the fact you have only VPN access to that server limits your liability and they know that you have access.</p>

<p>Often internet usage in industrial network is restricted, which is why for me it's the best solution, as asking to have your equipment able to talk to the internet (the way around) could often be an issue.</p>

CC BY-SA 4.0
2018-11-28T13:21:02.857Z
2018-11-30T10:39:21.373Z
2018-11-30T10:39:21.373Z
yagmoth555
<p>If organizations which manage firewall host and infra around can create a user for you on their equipment - you can use the advantage of "jump host".
Imagine you have access to host A and host A has connectivity with host B. Then you can do it with the following ssh config.</p>

<pre><code>Host A
  Username username
  Hostname bloody.enterprise.example
Host B
   ProxyJump A
</code></pre>

<p>If it's not an option.Well, you can consider setting up VPN.</p>

CC BY-SA 4.0
2018-11-28T10:47:00.523Z
2018-11-28T10:47:00.523Z
reflector
<p>I'm working on a deployment that will require me to place Ubuntu servers that monitor industrial equipment at various sites and behind firewalls that are out of my control.  I need to maintain SSH access to the servers to perform maintenance and updates, but am struggling on the best way to securely accomplish this.</p>

<p>Port forwarding and creating firewall pinholes are not options, so I can't quite get my head around what to do.  Is there some system that I could use to maintain the ability to open an SSH tunnel to these machines from the outside world?  Is there a better way to accomplish this?</p>

<p>Thanks!</p>

CC BY-SA 4.0
2018-11-30T03:07:22.883Z
Would https://guacamole.apache.org/ help?
chicks
<linux>
SSH tunneling to hosts deployed behind firewalls
Neal L
# SSH tunneling to hosts deployed behind firewalls

(Asked by: username_0 on 2018-11-28)

I'm working on a deployment that will require me to place Ubuntu servers that monitor industrial equipment at various sites and behind firewalls that are out of my control. I need to maintain SSH access to the servers to perform maintenance and updates, but am struggling on the best way to securely accomplish this.

Port forwarding and creating firewall pinholes are not options, so I can't quite get my head around what to do. Is there some system that I could use to maintain the ability to open an SSH tunnel to these machines from the outside world? Is there a better way to accomplish this?

Thanks!

**Tags:** linux

> **Comments:**
> **username_1**: Would https://guacamole.apache.org/ help?  

---

## 3 answers

### Answer by username_2 on 2018-11-28. Score: 1

Assuming that the monitoring host is able to make *outbound* connections, you can solve this by having a [bastion host](https://en.wikipedia.org/wiki/Bastion_host) elsewhere which you can connect through. Obviously do make sure to clear this with your customer.

To do this, set up a server somewhere under your control. This might be a VPS with a generous traffic limit, or it might be a physical server under your control, or something else. Give it a stable DNS name, possibly on a one-per-customer basis, which maps to the IP address of the bastion host. Mind the possibility that you may need to renumber that host in the future, possibly without being able to access the monitoring host.

Now, configure the monitoring host (the one that you want to be able to ultimately connect to) to connect *out* to the bastion host to set up a SSH tunnel. This will probably include creating a non-privileged username_2 account on the monitoring host to run the tunnelling SSH process, and protecting that appropriately. (Remember: this account won't be used for logging in to; it will only run a local, non-interactive SSH client process, and own the tunnel.) Also set up a non-privileged account on the bastion host, with only sufficient privileges to log in with SSH (not to a shell) and set up a SSH tunnel to the monitoring host.

With that in place, you can set up something like `autossh` on the monitoring host to maintain a connection to the bastion host to keep the tunnel alive. Add some decent logging on the bastion host, since on the monitoring host, the connection will almost certainly look like it originates from localhost.

When you need to connect to the monitoring host, first connect to the bastion host setting up a SSH tunnel to the bastion host's local port that forwards to the monitoring host; and then connect to the local port that maps to that tunnel. This will tunnel the SSH traffic *via* the bastion host, allowing your system to talk to the ultimate target host without requiring the host that is ultimately being connected to to be able to accept incoming connections.


---

### Answer by username_3 on 2018-11-28. Score: 0

Officially, you should ask those firewall admins to create you a VPN access on each router, optionally ask them to have only access to your server behind their firewall.

That will leave you a username_2 account to manage your updates, while at the same time you will be covered legally: if a leak happens, or a security issue happen, the fact you have only VPN access to that server limits your liability and they know that you have access.

Often internet usage in industrial network is restricted, which is why for me it's the best solution, as asking to have your equipment able to talk to the internet (the way around) could often be an issue.


---

### Answer by username_4 on 2018-11-28. Score: 0

If organizations which manage firewall host and infra around can create a username_2 for you on their equipment - you can use the advantage of "jump host".
Imagine you have access to host A and host A has connectivity with host B. Then you can do it with the following ssh config.
Host A
  Username username_2name
  Hostname bloody.enterprise.example
Host B
   ProxyJump A

If it's not an option.Well, you can consider setting up VPN.


---

