I have set up a reverse-ssh appliance with a Raspberry-Pi for use at a customer site to connect to a piece of equipment I have to support via a USB-to-RS232 adapter. I've cleared this with the customer's IT staff, and the appliance is already configured, tested and working fine.

But in the interest of hardening it from local-net access, I would like to restrict logins to only allow login through the reverse SSH tunnel, and not allow anyone on the local customer's network to login.

The outgoing reverse-ssh connection uses a 4096-bit keyfile with no password to connect to the server, but I still see a user/password prompt when I connect back from the server to the Pi through the reverse ssh connection. That's not a problem for me, but I was just concerned about limiting the ability of anyone locally to log in with a local telnet or ssh. I already have a good password on the only active account, so I doubt that anyone would manage to log in anyway.

It would be good if it still allowed logins on the local machine with an attached USB keyboard for maintenance purposes, but that's not mandatory. The device is inside a locked metal enclosure in a locked room, so unauthorized physical access is not a great concern. I just want to lock out local-network access to telnet & ssh logins while still allowing ssh logins through the reverse ssh tunnel.

  • Wait, I'm a little confused by what you mean by reverse-ssh connection. Is the RPi actively connecting to the server and performing a reverse tunnel (ssh -R) or is the server connecting to the RPi and then tunneling the port (ssh -L). In other words, the "outgoing" connection is RPi->server or server->RPi?
    – grochmal
    Aug 22, 2016 at 1:30
  • It is running ssh -R - reverse tunnel. Aug 22, 2016 at 2:30

2 Answers 2


For your RPi's ssh daemon, look at sshd_config and the AllowUsers option. You can specify hostnames in that.

Since you're reverse tunnelling then it's possible that the connection is from localhost and so

AllowUsers yourusername@localhost

in /etc/ssh/sshd_config (or wherever your OS puts it) might be sufficient. Remember to restart sshd (or just SIGHUP it) after changing sshd_config.

Since you're only touching sshd then serial console logins won't be impacted.

  • yes, when I connect back through the reverse tunnel, it shows up as localhost. I was wanting to know if there's a way to restrict any other logins that don't come through that reverse tunnel, so that if someone stumbles across the local net (192.168.x.x) IP address, that they would be unable to login. But I suppose that if someone manages to login, they're going to be coming from localhost, too. I'm just looking to cover my bases so that even if someone discovers an exploit that gets them logged in, I could limit the extent of the breach. Aug 22, 2016 at 2:35
  • If someone doesn't come from the tunnel then it'll show as coming from their remote IP address (eg and so the AllowUsers rule will block it. Only ssh connections originating from the machine (eg people already logged in, or from the tunnel) will originate from localhost. The address in the restriction is the remote address the login originates from. Aug 22, 2016 at 2:45

Since it it that RPi that is connecting to the server and then creating a reverse SSH tunnel, you can run sshd on localhost on the RPi.

First of all add a bind_address to the reverse tunnel command, i.e. perform the ssh call from the RPi to the server as:

ssh -R localhost:6060:localhost:22 -i path/to/key me@server

Yes, that is localhost two times:

  • localhost:22 is where the traffic is redirected on the RPi.
  • localhost:6060 is the port that will listen on the server (you may or may not wish this to be on localhost, since the server is available from the internet you probably what this to be localhost).

Now, on the RPi you can add to /etc/ssh/sshd_config the following:


And restart sshd.

Now the RPi will reject connections on the local network to port 22 because the socket is bound to localhost (on loopback, a different interface from the one with the local IP), yet it will answer the reverse SSH tunnel because that socket explicitly binds to localhost on the RPi's side of the tunnel.

ssh -p 6060 user@rpi

Will connect from the server to the RPi as normal.

Note: This may be dangerous, since there is no easy way to make the RPi answer to connections from the local network again. The only way to fix things if something breaks very badly is to go there and connect a screen and a keyboard. Seriously, test it first, if you make a typo somewhere you will need physical access.

Note 2: The only real difference between this solution an Stephen Harris' one is that the RPi will now reject connections to port 22. Whether you want that or want it to accept the connections and just reject the authorisation, is a matter of preference (or honeypot design :) )

  • @stephen-harris also - Thanks for some very informative answers. I really appreciate the explanations. Those will let me feel more secure against some opportune hacker. Aug 22, 2016 at 23:00

You must log in to answer this question.

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