Recipe 3.7 Restricting Access by Remote Users

3.7.1 Problem

You want only particular remote users to have access to a TCP service. You cannot predict the originating hosts.

3.7.2 Solution

Block the service's incoming TCP port with a firewall rule [Recipe 2.6], run an SSH server, and permit users to tunnel in via SSH port forwarding. Thus, SSH authentication will permit or deny access to the service. Give your remote users SSH access by public key.

For example, to reach the news server (TCP port 119) on your site server.example.com, a remote user on host myclient could consruct the following tunnel from (arbitrary) local port 23456 to the news server via SSH:

myclient$ ssh -f -N -L 23456:server.example.com:119 server.example.com

and then connect to the tunnel, for example with the tin newsreader:

myclient$ export NNTPSERVER=localhost
myclient$ tin -r -p 23456

3.7.3 Discussion

SSH tunneling, or port forwarding, redirects a TCP connection to flow through an SSH client and server in a mostly-transparent manner.^[1] [Recipe 6.14] This tunnel connects from a local port to a remote port, encrypting traffic on departure and decrypting on arrival. For example, to tunnel NNTP (Usenet news service, port 119), the newsreader talks to an SSH client, which forwards its data across the tunnel to the SSH server, which talks to the NNTP server, as in Figure 3-2.

^[1] It's not transparent to services sensitive to the details of their sockets, such as FTP, but in most cases the communication is fairly seamless.

Figure 3-2. Tunneling NNTP with SSH

By blocking a service's port (119) to the outside world, you have prevented all remote access to that port. But SSH travels over a different port (22) not blocked by the firewall.

Alternatively, investigate whether your given service has its own user authentication. For example, wu-ftpd has the file /etc/ftpaccess, sshd has its AllowUsers keyword, and so forth.

3.7.4 See Also

ssh(1), sshd(8), tin(1).