Allow reverse SSH tunnel but not simple SSH

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?

Solution 1:

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.