Can a SSH reverse tunnel accept non-local connections?

Question

I have a server in my office behind a firewall, a home server behind NAT, and a laptop I carry around. Sometimes I want to reach the office server from home so I did the following setup.

Home router redirects port 2223 to homeserver port 22.

I am running a reverse-tunnel from the office, using autossh and a systemd unit:

[Unit]
Description=Call home using port 2223 and reverse tunnel 22222 into 22
After=network.target

[Service]
User=atilla
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -p 2223 -N -R 22222:localhost:22 atilla@my_home_ip

[Install]
WantedBy=multi-user.target

On my homeserver, I can do ssh -p 22222 localhost and connect to the office server. However, when at home, doing ssh -p 22222 homeserver.local, the connection gets refused. I always have to log into homeserver and do another hop.

The office server uses latest Raspbian, homeserver is on Ubuntu 22.04, all default settings.

Answer 1

Reading about autossh I see that aside from a few flags, "all other arguments are passed to ssh". The specification for the ssh -R flag is shown in the manpage with man ssh:

-R [bind_address:]port:host:hostport

In your configuration you've (quite reasonably) omitted the optional bind_address: part so the bind is only available to the local machine. Include the colon and an undefined bind_address becomes the wildcard *, which makes the port accessible from anywhere (subject to firewalls, routing, and other network management layers).

ExecStart=/usr/bin/autossh -p 2223 -N -R *:22222:localhost:22 atilla@my_home_ip

You may also need to read up on and change the setting of GatewayPorts for the sshd service. By default its value is no, which prevents you doing what I've just described. See man sshd_config for details including the alternative options yes and clientspecified. Don't choose a value without reading up about it.

---

Having answered this, I should point out that by having an unmanaged ingress into your office network may well be a breach of IT Policy and could result in disciplinary proceedings. Particularly for a route that's about to be accessible from "anywhere".

Answer 2

For sake of completeness, I am sharing another solution I found: using a feature called SSH jump host.

With the above ssh tunnel, this command can connect to the office server in a single go

ssh -J homeuser@homeserver:22 -p 22222 workuser@localhost

The -J flag tells to use user@server:port account as the jump host, and the later are SSH arguments from the point of the jump host.