Softpanorama
(slightly skeptical)
Open Source Software Educational Society
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
| 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-2009 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). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
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: August 12, 2009