Allow reverse SSH tunnel but not simple SSH

Question

I have a computer (let's name it A) behind a NAT, and I need a SSH connection to it from another computer (let's name it B).

I saw that I needed an SSH reverse tunnel, I tried, and it works.

In order to make the reverse tunnel work, I had to add the public key of A in the authorized_keys file of B.

The problem is that (for security concerns) I don't want computer A to be able to ssh in the computer B and see/modify the files in it (A is kind of a slave of B).

Is it possible to avoid this?

So someone bad might have physical access to A and you want to protect B? — phk, Nov 05 '15 at 12:30
I might have simply suggested to you that the account on B for A to connect to would have to be very restricted so much that he can't do anything else (similar how you would do for a SCP-only server) but I am not sure myself how reliable that really is. — phk, Nov 05 '15 at 12:43
I thought about creating a chroot-jailed restricted user on B, but then, will I be able to connect from B to A with a non-restricted user even though the reverse tunnel is open for the restricted one ? (and how do I authorize A to connect only to the restricted user ?) — 4rzael, Nov 05 '15 at 12:54

Kamil Maciorowski · Accepted Answer · 2022-01-07T06:28:49.070

a computer (let's name it A) […] another computer (let's name it B). […] I had to add the public key of A in the authorized_keys file of B.

A common situation is to add the public key of particular user of A in the auhorized_keys file of particular user of B. It's not the key represents the whole computer A; similarly the authorized_keys file doesn't belong to the whole B.

You probably added the public key of some user alpha of A in the authorized_keys file of some user beta of B (the two users may use the same login, still they are on different machines, so let's keep distinct names alpha and beta).

My solution: set beta's login shell on B to /bin/false. You can do this (on B) with sudo usermod -s /bin/false beta.

This would cause the following restrictions:

beta cannot normally log into B at all; in particular ssh beta@B from A won't give anyone a shell, despite SSH authentication success;
commands like ssh beta@B whatever won't succeed;
neither SCP nor SFTP^* trying to access beta's account won't work (see this comment).

It looks like there is no way for alpha on A to see or modify the files in B. However at the same time:

anyone able to authorize as beta can use ssh -N to establish SSH connection to B without running any command there; this is an example command alpha should invoke on A:
```
  ssh -N -R 1234:127.0.0.1:22 beta@B
```
you don't have to be beta to use the tunnel (although -R without specifying a bind address will bind only to the loopback interface of B, so you have to be on B to use the tunnel; see also man 5 sshd_config, GatewayPorts option).

Additionally check MaxSessions and PermitOpen options in man 5 sshd_config. I think if you use them properly then a possible attacker using alpha's private key won't be able to "capture" too many ports on B.

* Exception: SFTP will work without a functional shell if the server is configured to use Subsystem sftp internal-sftp.

Allow reverse SSH tunnel but not simple SSH

1 Answers1