A secure command line interface is just the beginning of the many ways SSH can be used. Given the proper amount of bandwidth, X11 sessions can be directed over an SSH channel. Or, by using TCP/IP forwarding, previously insecure port connections between systems can be mapped to specific SSH channels.
Opening an X11 session over an established SSH connection is as easy as running an X program while already running an X client on your host. When an X program is run from the secure shell prompt, the SSH client and server create a new secure channel within the current SSH connection, and the X program data is sent over that channel to your client machine as if you were connected to the X server via a local terminal.
As you might imagine, X11 forwarding can be very useful. For example, you can use X11 forwarding to create a secure, interactive session with the up2date GUI on the server to selectively update packages (if you have the necessary Red Hat Network packages installed on the server). To do this, simply connect to the server using ssh and type:
up2date |
You will be asked to supply the root password for the server. Then, the Red Hat Update Agent will appear and you can update your packages on the server as though you were sitting in front of the machine.
The processing overhead required to encrypt and decrypt the secure information being sent over the channel, plus the extra bandwidth necessary to send encrypted X application data, may be significant, however. Adequate testing is required to make sure that the X program is still usable, given your particular hardware and bandwidth conditions.
TCP/IP forwarding works with the SSH client requesting that a particular port on the client or server side be mapped over the existing SSH connection.
To map a local port on the client to a remote port on the server, you first have to know the port numbers on both machines. It is even possible to map two non-standard, different ports to each other.
To create a TCP/IP forwarding channel which listens for connections on the local host, use the following command (all on one line):
ssh -L <local-port>:<remote-hostname>:<remote-port> <username>@<hostname> |
Note | |
---|---|
Setting up TCP/IP forwarding to listen on ports below 1024 requires root access, just as starting services that listen on ports below 1024. |
For example, if you want to check your email on a server called mail.domain.com using POP and SSH is available on that server, you can use this command to set up TCP/IP forwarding:
ssh -L 1100:mail.domain.com:110 mail.domain.com |
After the TCP/IP forwarding is in place between the two machines, you can direct your POP mail client to use localhost as the POP server and 1100 as the port to check for new mail. Any requests sent to port 1100 on your system will be directed securely to the mail.domain.com server.
If mail.domain.com is not running an SSH server daemon but you can log in via SSH to a machine near it, perhaps through a firewall, you can still use SSH to secure the part of the POP connection that occurs over public networks. A slightly different command is needed:
ssh -L 1100:mail.domain.com:110 other.domain.com |
In this example, you are forwarding your POP request from port 1100 on your machine through the SSH connection on port 22 to other.domain.com. Then, other.domain.com connects to port 110 on mail.domain.com to allow you to check for new mail. Only the connection between your system and other.domain.com is secure, but in many situations, this is enough to get your information safely through public networks by providing more security than you had before.
Of course, in this example and the one above it, you must be able authenticate to the SSH server to perform the TCP/IP forwarding. Be sure that you can execute normal SSH commands before attempting to set up TCP/IP forwarding.
TCP/IP forwarding can be particularly useful for getting information securely through network firewalls. If the firewall is configured to allow SSH traffic via its standard port (22) but block access through other ports, a connection between two hosts using the blocked ports is still possible by redirecting their communication over an established SSH connection between them.
Note | |
---|---|
This can be very dangerous, however. Using TCP/IP forwarding to forward connections in this manner allows any user on the client system to connect to the service you are forwarding connections to, which can be hazardous if your client system becomes compromised. Check with the system administrator who administers your firewall before using TCP/IP forwarding to bypass it. System administrators concerned about TCP/IP forwarding can disable this functionality on the server by specifying a No parameter for the AllowTcpForwarding line in /etc/ssh/sshd_config and restarting the sshd service. |