Secure Shell can enscapsulate TCP-based application data streams and then tunnel them across its secure connection to and from the client and server. This is referred to as port forwarding. Port forwarding is useful for securing communications with legacy platforms or internal systems such as the internal web site, internal Internet relay chat (IRC) network, or email access.
Port forwarding is not transparent to the application. The application requires some configuration to use the forwarded ports. For situations requiring transparency, a network-level solution such as IPsec or VPNs must be used. Port forwarding will not work for UDP-based protocols or for protocols, such as IRC DCC channels, that dynamically allocate a second data stream on a separate port.
Ports to be forwarded can either be specified on the command line or in the client configuration file (recommended for a system with multiple forwarded port). Forwarded ports can also be local (from client to server) or remote (server to the client). Port forwarding and RBAC can provide secure access to an IMAP mail server while preventing the users from having access to the server itself.
The following two examples show the local forwarding of port 8080 on the client to port 80 on the server.
This example shows forwarding using the ssh(1) command:
$ ssh -L8080:server:80 server
This example shows forwarding using the client's configuration file:
Host server LocalForward 8080 server:80
The Solaris Secure Shell software disables port forwarding by default. See "Connection and X11 Forwarding" on page 46 for more details.
To Secure WebNFS Mounts With Port Forwarding
Choose an unused local port and forward it to the WebNFS port on the server.
Become the superuser.
Mount the file system using the forwarded port.
A different local port will be needed for each server. This connection must be maintained for the life of the mount.
$ ssh -f -N -L3030:server:2049 server
# mount nfs://localhost:3030/export/home /mnt
This procedure provides transport-level protection only for the WebNFS traffic. Using Secure Shell in this manner does not provide additional WebNFS authentication.