
ssh: We pull out a foreign port for ourselves because of NAT

What ssh -R does © erik, unix.stackexchange.com
Connect to the service for NAT, having a person next to the service, armed with ssh, and a white ip at home.
Option -R
There is a mode in ssh in which it opens a port on the server and, through a tunnel from server to client, redirects connections to the specified address on the client’s network.
That is, we need to raise sshd, ask the person to execute
$ ssh -N -R server_port: target: target_port sshd_server
And on our machine with sshd, the server_port port will open, which will be tunneled to target: target_port on this person’s network.
How to restrict rights in sshd_config
ForceCommand echo "no shell access is given"
If you set this option, then the specified command will be executed instead of any transmitted by the client (usually the client starts the shell).
Since scp works through the [built-in] sftp command, copying files will also be closed.
Tunneling (forwarding) still works.
AllowTcpForwarding remote
Allows tcp tunneling modes:
- local (option -L in ssh) - open the port on the client and redirect connections to the address specified by the client on the server network
- remote (option -R) - open the port on the server and tunnel connections to the address specified by the client on its network
- all or yes - allows both local and remote
- no - prohibits tcp tunnels
Match
As usual, the above options can be put in the section, for example, Match User tunnel , and they will be valid only for connections authenticated under the name of this user. (ssh ... tunnel @ sshd_server)
Put sshd_config at the end and remember to create the tunnel user
Match user tunnel ForceCommand echo "no shell access is given" AllowTcpForwarding remote # in case we have globally installed otherwise: X11Forwarding no PermitTunnel no
It would also be nice to limit the ports that the client can occupy on the server, but without patches to sshd this can not be done .
More convenient and without root
I would like to solve the problem in the spirit of netcat: do not touch the system sshd, do not create new users and do not start daemons.
sshd can be run without root if you make a separate config and disable several options. (However, he will not be able to accept users other than the one with which he was launched). You must also specify a separate HostKey and a separate PidFile.
The authentication problem will remain. Since sharing your own system password (and we are not going to create a separate user) with clients is wrong, you need to leave only authentication by keys and specify a separate file with them.
In addition, it is convenient to run the resulting sshd without demonization and with a log in the console to monitor how the tunnels are created.
Ready script:running custom sshd limited to creating tunnels .