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:
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.
|