Reverse tunneling SSH keys with port limitations on both ends?

Turbocapitalist · 04-17-2021, 10:15 AM

I am looking to find a way to use public key options, or any other method, to forceably limit ports on both ends of a reverse tunnel over SSH.

If I set up a reverse tunnel initiated from system A to system B, where port 4406 on B is connected to port 3306 on A:

Code:

ssh -R 4406:localhost:3306 serverB.example.com

I can then limit the choice of port available on B by using the PermitListen option within the public key as recorded in system B's account's authorized_keys file.

Code:

$ hostname 
serverB.example.com

$ grep -w 4406 ~/.ssh/authorized_keys

restrict,port-forwarding,permitlisten="localhost:4406" ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCmE1i8zP2Edb+JJv0dYHwhn0d91cqJTrhT8AiiidE6GdfMQqQtwBQ5jcm+PLeJ5Fw6OGPMTKRGCRFXpvtPUfyI=

How do I then also limit the choice of ports on the other end of the connection? That is to say, limit which port the key can use on the originating system. I've experimented with the PermitOpen option but it is not relevant here because it affects only -L regular forwarding, not reverse forwarding. I expect I have missed something fairly obvious?

allend · 04-19-2021, 09:29 AM

I am not sure of the use case here. Are you saying that you wish to demonstrate that a user that is trusted with a key and has accessed system A should not be allowed to do something like set up a cron job to setup a tunnel with 'ssh -R 4406:localhost:5506 serverB.example.com'.

Perhaps firewall restrictions on outgoing connections on serverA?

Turbocapitalist · 04-19-2021, 09:54 AM

The use-case would be for an automated script using a key without a passphrase. There, I figure the more locked down the better as a reminder that the key is single-purpose. But, yes, there is trust involved either way.

The absence of a passphrase would be in contrast to setting up a one-off SSH agent just for that script and manually loading the key into the agent as needed.

Maybe rejecting all outbound ports on serverA, with a small subset allowed, would be one way, but seems fiddly on a system still a while away from transitioning from development to production.