|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
| News | SSH | Recommended Links | Mini-tutorial | Humor | Etc |
Not only can SSH forward your authentication requests, but it can forward
your X Window System traffic as well. And SSH not only forwards the traffic,
but also automatically sets X's DISPLAY variable on the remote system, thus simplifying
your side of things substantially. Nobody likes messing with the DISPLAY variable,
Magic Cookies, or any other part of remote X configuration. SSH can handle all of
those at once. You just need to connect SSH using the -X option, or set
ForwardX11 yes in the appropriate config files, and
run your X application from the remote system's command prompt.
When using X, I always make sure to turn compression on with the -C option (Compression
yes in the config file), as X is bandwidth-intensive, to put it politely.
With compression on and a fast cipher such as blowfish (the default for recent versions
of OpenSSH), Netscape is just about usable over a 10-Mb network. Without compression,
it is rather painful, and I would certainly not recommend running any complex X
application on less than 10 Mb.
Perhaps even more interesting is SSH's ability to forward arbitrary ports. Maybe
you read mail on a server that you can also SSH into, and POP3 mail is running while
secure POP3 is not. You therefore wish to forward a port on your workstation to
the POP3 port on the server. Let's pick an arbitrary port, such as 2048. Configure
your mail client (such as Netscape) to connect POP3 to port 2048 on localhost (that
is, your workstation). Then you can run the following command:
ssh -N -f -L 2048:mailserver.example.com:110 you@mailserver.example.com
and you'll be able to connect securely.
What's happening here? -N tells SSH that you're not interested in running a command
on the remote system, only in forwarding the connection, and -f tells SSH to go
into the background once you've authenticated your connection. That way, after you've
entered your passphrase (or once ssh-agent has authenticated you), you won't need
to type more. The magical part is -L 2048:mailserver.example.com:110.
That tells SSH to forward the local port 2048 to mailserver.example.com's port 110.
(Port 110 is the standard POP3 port.) So you log in to the mail server, and then
anything on local port 2048 is sent over the SSH connection to port 110 on the remote
side, thus allowing you to safely retrieve your mail.
That method works very nicely for most protocols, including POP3, HTTP, and IMAP, just so long as you're able to tell the client server to use the local system and the appropriate port on your local system. For FTP, be sure to use passive FTP, because active FTP opens a second connection that will not be forwarded via the SSH port forwarding. Recent versions of OpenSSH, and Commercial SSH version 2, support SFTP, which works like FTP and uses SSH without the difficulty of port forwarding and passive mode.
In addition to X11 forwarding, ssh can also be used to forward connections from one port to another, otherwise known as port forwarding or tunneling. Port forwarding can be used to make an otherwise unencrypted connection secure by encrypting it via ssh. It can also be used to connect to a server behind a firewall.
The basic syntax is as follows:
ssh -L <localport>:<remotehost>:<remoteport> <username>@<otherhost>
When a connection is made to port <localport> on the local system, the connection goes over an encrypted tunnel to the <otherhost> and then is forwarded to port <remoteport> on the <remotehost> after successful authentication for username@otherhost.
SSH tunnel is established
between the source host and the SSH server.
The destination host can be any type of server configured to accept connections
on a static port such as a POP3 email server, a web server, or even another
SSH server.
The destination host allows connections from the SSH server through the firewall, but the firewall does not allow connections from the source host. So, an encrypted SSH tunnel is established between the source host and the SSH server. Then, packets intended for the destination host are sent over the encrypted tunnel to the SSH server and then forwarded to the destination host on the other side of the firewall. The connection between the SSH server and the destination host is not necessarily encrypted because 'an SSH tunnel has not been established between them. However, the connection can be secured with additional software such as a VPN solution. If the destination host is another SSH server, the connection between the connecting SSH server and the destination host is encrypted because of the SSH connection.
Tip
To disable port forwarding on an OpenSSH server, add the following line to /etc/ssh/sshd_config:
AllowTcpForwarding no
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Chapter 11: SSH Port Forwarding
FreeBSDZine.org: SMTP over an SSH Tunnel(May 20, 2001)
Kermit File Transfer and Management as an SSH Subsystem Kermit 95 1.1.21 and later have an SSH client built in, so making SSH connections to the Kermit subsystem is perfectly straightforward...
LinuxSecurity: Encrypted Tunnels using SSH and MindTerm(May 19, 2001)
Re Piping VNC thru ssh Re: Piping VNC thru ssh
Last modified: June 02, 2008