SSH’s forwarding (or tunneling) features protect other TCP/IP-based applications by encrypting their connections. We cover forwarding in great detail in Chapter 9, but we introduce here the serverwide configuration keywords for controlling it.

TCP port forwarding can be enabled or disabled by the keyword AllowTcpForwarding, with the value yes (the default) or no:

    AllowTcpForwarding no

Tectia can specify this more selectively for particular users or Unix groups, with the keywords AllowTcpForwardingForUsers, AllowTcpForwardingForGroups, DenyTcpForwardingForUsers, and DenyTcpForwardingForGroups:

    # Tectia
    AllowTcpForwardingForUsers smith
    AllowTcpForwardingForGroups students
    DenyTcpForwardingForUsers evildoer
    DenyTcpForwardingForGroups badguys

The values for these keywords use the same syntax as for AllowUsers, AllowGroups, DenyUsers, and DenyGroups, respectively: [5.5.1] [5.5.2]

    # Tectia with zsh_fileglob or traditional regex syntax
    AllowTcpForwardingForUsers good*@*.friendly.org,*@\i10.1.2.*,12[[:digit:]]
    DenyTcpForwardingForGroups bad*,33[[:digit:]]

    # Tectia with egrep regex syntax
    AllowTcpForwardingForUsers good.*@.*\.friendly\.org,.*@\i10\.1\.2\.*,12[[:digit:]]
    DenyTcpForwardingForGroups bad.*,33[[:digit:]]

Tectia’s ForwardACL keyword provides the most precise access control for specific forwardings.^[78] Its use is complicated but it provides great flexibility. It uses multiple values (separated by whitespace), with the general format:

    # Tectia
    ForwardACL access direction client forward [originator]

The values stand for:

A trusted user could then run her SSH client on somewhere.friendly.org as:

    $ ssh -L2001:mail.example.com:143 ssh.example.com

where ssh.example.com is the host that runs the SSH server. Note that no restrictions are imposed on the listening port for local forwardings (2001 in this case); the SSH server has no reason to care about that, and no way to verify it anyway.

To allow guest users (i.e., those whose usernames start with “guest”) initiating SSH connections from a range of addresses described by the netmask 10.1.2.0/24 to use remote forwarding, but only listening on the localhost interface and accepting forwarded connections on a range of ports 7000-7009:

    # Tectia with zsh_fileglob or traditional regex syntax
    ForwardACL allow remote guest*@\m10.1.2.0/24 localhost:700[[:digit:]]

    # Tectia with egrep regex syntax
    ForwardACL allow remote guest.*@\m10.1.2.0/24 localhost:700[[:digit:]]

The user guest33 could then run his SSH client on a host with address 10.1.2.3 as:

    # Tectia
    $ ssh -Rlocalhost:7005:server.elsewhere.net:8080 ssh.example.com

Note that there are no restrictions on the target for the forwarding (port 8080 on server.elsewhere.net); the SSH server again neither knows nor cares about the forwarded connection on the SSH client side.

To relax this access control, allowing the SSH server to accept connections on any listening address, but only from application clients originating forwarded connections from hosts in the outbound.example.com domain, replace the localhost component in the previous forward pattern with a “match anything” wildcard, and add a fifth originator pattern:

    # Tectia with zsh_fileglob or traditional regex syntax
    ForwardACL allow remote guest*@\m10.1.2.0/24 *:700[[:digit:]] *.outbound.example.com

    # Tectia with egrep regex syntax
    ForwardACL allow remote guest.*@\m10.1.2.0/24 .*:700[[:digit:]] .*\.outbound\.example\.com

ForwardACL restrictions for local and remote forwardings are completely independent. If any ForwardACL keywords allow specific, limited access for either kind of forwarding, then all other access for that kind of forwarding will be denied.

Tectia uses the most restrictive interpretation for forwarding access control: if multiple ForwardACL keywords match a requested forwarding, and any of them deny access, then the forwarding is rejected. This can be useful for creating exceptions. For example, to allow local forwarding to any port on any target host in the example.com domain, but not to any port on the database server db.example.com, or to http servers (port 80) on any example.com hosts:

    # Tectia with zsh_fileglob or traditional regex syntax
    ForwardACL allow local  *  *.example.com
    ForwardACL deny  local  * db.example.com
    ForwardACL deny  local  *  *.example.com%80

    # Tectia with egrep regex syntax
    ForwardACL allow local .* .*\.example\.com
    ForwardACL deny  local .* db\.example\.com
    ForwardACL deny  local .* .*\.example\.com%80

Furthermore, ForwardACL keywords cannot override restrictions imposed by the other forwarding access control keywords (AllowTcpForwardingForUsers, AllowTcpForwardingForGroups, DenyTcpForwardingForUsers, DenyTcpForwardingForGroups, or AllowTcpForwarding): if any of these applicable keywords deny access for a requested forwarding, then the forwarding is forbidden.

Forwarding for X, the popular Window System, can be separately enabled or disabled with the keyword X11Forwarding:^[81]

    X11Forwarding no

OpenSSH automatically disables X11Forwarding if UseLogin is enabled. [5.4.10]

Administrators may wish to disable forwarding for users who are not trusted to have forwarding securely configured on the client side. For example, it is usually desirable to avoid SSH clients that indiscriminately accept connections from anywhere, and then forward them across SSH tunnels to trusted servers. Similarly, misconfigured X servers (which run on the SSH client side) can expose X client programs running on the SSH server side to attack, if the X server access is overly permissive.

Disabling forwarding isn’t effective for users who are granted shell access to run arbitrary commands, because such users can use their own programs to set up equivalent forwarding functionality. For better control, set up special-purpose accounts that use carefully written, restricted programs instead of standard shells, and consider using subsystems. [5.8]

Agent forwarding permits a series of SSH connections (from one machine to another to another, ...) to operate seamlessly using a single agent. [6.3.5] Agent forwarding may be enabled or disabled in the Tectia server using the keyword AllowAgentForwarding with a value of yes (the default) or no:^[82]

    # Tectia
    AllowAgentForwarding no

It may also be enabled or disabled by OpenSSH and Tectia clients. [6.3.5.3]

Agent forwarding is convenient, but in a security-sensitive environment, it might be appropriate to disable this feature. Because forwarded agent connections are implemented as Unix domain sockets, an attacker can conceivably gain access to them. These sockets are just nodes in the filesystem, protected only by file permissions that can be compromised.

For example, suppose you maintain a network of exposed, untrusted machines that you access from a more secure network using SSH. You might consider disabling agent forwarding on the untrusted machines. Otherwise, an attacker can compromise an untrusted machine; take control of a forwarded agent from a legitimate, incoming SSH connection; and use the agent’s loaded keys to gain access to the secure network via SSH. (The attacker can’t retrieve the keys themselves in this way, however.)