SSH Tunneling

OpenSSH has the ability to create a tunnel to encapsulate another protocol in an encrypted session.

The following command tells ssh to create a tunnel for telnet:

% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com

The ssh command is used with the following options:

-2

Forces ssh to use version 2 of the protocol. (Do not use if you are working with older SSH servers)

-N

Indicates no command, or tunnel only. If omitted, ssh would initiate a normal session.

-f

Forces ssh to run in the background.

-L

Indicates a local tunnel in localport:remotehost:remoteport fashion.

user@foo.example.com

The remote SSH server.

An SSH tunnel works by creating a listen socket on localhost on the specified port. It then forwards any connection received on the local host/port via the SSH connection to the specified remote host and port.

In the example, port 5023 on localhost is being forwarded to port 23 on localhost of the remote machine. Since 23 is telnet, this would create a secure telnet session through an SSH tunnel.

This can be used to wrap any number of insecure TCP protocols such as SMTP, POP3, FTP, etc.

Example 1: Using SSH to Create a Secure Tunnel for SMTP

% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
user@mailserver.example.com's password: *****
% telnet localhost 5025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP

This can be used in conjunction with an ssh-keygen and additional user accounts to create a more seamless/hassle-free SSH tunneling environment. Keys can be used in place of typing a password, and the tunnels can be run as a separate user.

Example 2: Secure Access of a POP3 Server

At work, there is an SSH server that accepts connections from the outside. On the same office network resides a mail server running a POP3 server. The network, or network path between your home and office may or may not be completely trustable. Because of this, you need to check your e-mail in a secure manner. The solution is to create an SSH connection to your office's SSH server, and tunnel through to the mail server.

% ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
user@ssh-server.example.com's password: ******

When the tunnel is up and running, you can point your mail client to send POP3 requests to localhost port 2110. A connection here will be forwarded securely across the tunnel to mail.example.com.

Example 3: Bypassing Firewall

Some network administrators impose extreme firewall rules, filtering not only incoming connections, but outgoing connections. You may be only given access to contact remote machines on ports 22 and 80 for SSH and web surfing.

You may wish to access another (perhaps non-work related) service, such as an Ogg Vorbis server to stream music. If this Ogg Vorbis server is streaming on some other port than 22 or 80, you will not be able to access it.

The solution is to create an SSH connection to a machine outside of your network's firewall, and use it to tunnel to the Ogg Vorbis server.

% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org
user@unfirewalled-system.example.org's password: *******

Your streaming client can now be pointed to localhost port 8888, which will be forwarded over to music.example.com port 8000, successfully evading the firewall.

Similarly you can view websites secure and anonymously:

% ssh -2 -N -f -L 8080:unblocked-proxy.web-server.com:80 user@ssh-server.example.org

In your browser setting, configure it to use proxy via 127.0.0.1 and 8080 as the port number.

When the tunnel is up, you can now browse the blocked websites secure and anonymously over your proxy server.

There are more interesting articles at Hacking Linux Exposed.

Reference:

OpenSSH.com

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

SSH port forwarding article

Below is a link to article at SecurityFocus that further explains SSH port forwards:

http://www.securityfocus.com/infocus/1816

X11 forwarding through SSH

If you need to have X11 forwarding for a connection, run ssh with the -X flag, for example:

$ ssh -X server /usr/bin/display filename.jpg

The -X option allows you to forward X connections (graphical programs) from the remote host to your desktop.

SSH has the ability to tunnel X11 connections through it - this feature is called X11 Forwarding. In brief, if you are on your desktop attached to an X11 display (you can run xclock for example) then when you SSH to a different machine, it can tunnel X11 over the connection. You can run graphical X11 applications on the remote machine, but they display back on your desktop.

Here is a bit of a working detail -- Upon logging into the remote system, the ssh server process binds a TCP port (let's say 6010), creates an MIT Magic Cookie on the server by running xauth, and then sets the $DISPLAY environment variable to point to it's port (for example $DISPLAY=localhost:10.0) When you run an X11 application, it reads the $DISPLAY variable, connects to the X11 server (in this case the sshd process on the remote system) and provides the magic cookie (by reading ~/.Xauthority). sshd verifies the cookie, and passes the data back to the ssh process on your desktop over the encrypted link. ssh on your desktop then forwards the data to the actual X11 server on your desktop, using the desktop's cookie. This also means that any time you SSH to another machine, that machine's administrators could attack you, which is definitely not good.

To turn off X11 forwarding by default, add the following to the
bottom of your ~/.ssh/config file, or the global /etc/ssh/ssh_config
file:

Host *
ForwardX11 no
ForwardAgent no
Comment