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?
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_keysfile 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;ssh beta@B whatever won't succeed;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.
