January 28, 2004 Edition

By Jorge Castro, Amit Gurdasani

 

Using SECSH port forwarding

Welcome back to another critically-acclaimed (not really) edition of Linux.Ars. On today's Internet, one can never be too careful, so much so that secure services are becoming increasingly common. So how do you protect your data while operating on the public net?

This week we are going to look at using the Secure Shell to wrap your remote connections, including X11, so that you can safely connect to remote hosts. Long a companion of experienced Sysadmins, ssh's versatility is guaranteed to bring you fewer headaches and more peace of mind. Then we will look at an SVG tool called Inkscape, and wrap it all up with a nice dose of /dev/random. So killall telnet and keep reading.

 

TTT: Tools, Tips and Tweaks Using SECSH port forwarding

Or how to have a private IM conversation past a nosy roommate's packet sniffer

SECSH (the Secure Shell protocol) must be one of the most versatile communications protocols in use today. It enables a secure channel of communications, not just for shell/terminal access, but also to enable secure transmission of just about any TCP-based protocol. This week, we cover its versatile applications.

Have you ever wanted to be able to access your home computer from a computer on a network you don't trust, access a GUI, run an IM or IRC client and so on, all securely? Have you ever wanted to access services on a network behind a firewall, without having to open ports for each service? If you have, you might be pleased to know that OpenSSH or one of the other implementations of the SECSH protocol will make it easy for you to do the above.

OpenSSH, specifically, is the most commonly installed implementation of the SECSH protocol, so we will make that our primary focus.

Terminal access

The simplest thing you can do with SSH is to access another computer, running the SSH server software, sshd. Invocation is simple:

[ amitg @ athena | ~ ] ssh user@host
Enter password:
[ user @ host | ~ ]

Password authentication is just one way to log in. It is also possible to set up a key pair for authentication a pair of strings encoding two large unique numbers, one "public" and the other "secret" or "private", where a message can be encrypted based on one of the keys and only decrypted with the help of the othee and, in fact, this can be done in a way such that the user need never type a password to authenticate to the remote computer. (Of course, things are safer but less convenient if a passphrase is used to protect the keys.) To set up keypair authentication, you need to run the ssh-keygen tool:

[ amitg @ athena | ~ ] ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/amitg/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/amitg/.ssh/id_dsa.
Your public key has been saved in /home/amitg/.ssh/id_dsa.pub.
The key fingerprint is:
01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef amitg@athena.localdomain
[ amitg @ athena | ~ ] ssh user@host sh -c "exec cat >> .ssh/authorized_keys2" < .ssh/id_dsa.pub
Enter password:

OpenSSH tries a number of authentication mechanisms before finally falling back to password authentication. (The authentication mechanisms tried are all configurable via /etc/ssh/ssh_config on the client side and /etc/ssh/sshd_config on the server side; even password authentication can be disabled.) If DSA or RSA key-pair authentication is available and the keys on both sides (in id_rsa/id_dsa on the client side and in authorized_keys2 on the server side) are complementary, the user is prompted for the passphrase, or not at all if there was no passphrase or if the user ran ssh-agent or similar at the beginning of the session. (ssh-add or similar will prompt you for the passphrase at the beginning of the X11 session and ssh-agent will make it available to any ssh clients invoked within that session, so that they will not need the passphrase typed again.)

[ amitg @ athena | ~ ] ssh user@host
Enter passphrase for key 'amitg@athena.localdomain':
[ user @ host | ~ ]

or even

[ amitg @ athena | ~ ] ssh user@host
[ user @ host | ~ ]

if a passphrase was not set or ssh-agent or similar was used.

There are also Kerberized OpenSSH clients and daemons available that can use Kerberos ticket authentication, so they do not prompt for a password if the user is properly authenticated via Kerberos. Also, since ssh is meant to be analogous to rsh in operation, it is possible to configure the client and daemon to use host-based authentication, where a list of trusted hosts (in the file .rhosts, .shosts, shosts.equiv, hosts.equiv, etc.) can be provided and clients from those hosts need not provide authentication. (Most security personnel consider this to be a major security risk, by the way key-pair authentication can do something similar with much more security; host-based authentication is provided mostly for backward compatibility with rsh.)

Port-forwarding

So far, we have just seen the boring side of SECSH: secure remote shells. However, ssh is a lot more flexible and capable than this.

For instance, say that you a're accessing a firewalled workplace network via SSH and would like to get to your email using a suitable IMAP4 client (e.g., Evolution) at home. However, the IMAP4 server is not exposed to the Internet, the port having been firewalled off (and perhaps, the IMAP4 server having a private IP address). Never fear, OpenSSH is here:

[ amitg @ athena | ~ ] sudo ssh -L 143:mail:143 user@host
Enter passphrase for key 'amitg@athena.localdomain':
[ user @ host | ~ ]

What is that -L, and what are the funny numbers and letters after it? The -L specifies that local connections to a certain port should be forwarded securely over the SSH connection to the SSH daemon side, and the SSH daemon should then connect to a particular port on a particular host. When a user connects to the local port (localhost:143, in this case), ssh picks up the connection, tells sshd on the other side of the connection to connect to mail:143 and allows data to be sent and received over the SSH link through the SSH daemon to the host (mail:143). The IMAP4 mail reader is configured to use localhost:143 as the IMAP4 server. Et voila the workplace e-mail is accessed transparently and securely over the big, bad Internet, from the remote network to your home computer.

(We have used sudo here because of the normal Linux stipulation that only the superuser, root, can have processes bind to a local port lower than 1024. In this case, ssh will attempt to bind to TCP port 143, and in order to be able to do that, it must typically run as root. The POSIX Capabilities system allows unprivileged users' processes to be given capabilities such as this, but capabilities are out of the scope of this write-up.)

Another thing that can be done is to securely tunnel VNC/RFB connections: we simply use -L 5901:remotehost:5901 (assuming that the VNC server is running on :1). There are good instructions available for this sort of use.

There is an -R option, too, which does the opposite it allows a server-side application to connect to a local port securely. It works in much the same way, with the roles of ssh and sshd reversed.

Finally, recent versions of OpenSSH actually have the ability for the ssh client to fake a SOCKS4 server. This enables even applications that do not use fixed ports to be usable, since they tell ssh via the SOCKS4 protocol what ports they expect to receive connections on and make connections to. This capability is enabled using the -D option:

amitg @ athena | ~ ] ssh -D 1080 user@host
Enter passphrase for key 'amitg@athena.localdomain':
[ user @ host | ~ ]

The -D 1080 option specifies that ssh should run as a SOCKS4 proxy server, accepting local connections from applications. The application can be configured to use localhost:1080 as the SOCKS4 server; most Web browsers, IM and file-sharing applications can be set up to use a SOCKS4 server. Those that cannot use a SOCKS4 proxy can be run using the tsocks library and utility in order to force TCP and UDP connections to go to the ssh SOCKS4 proxy server.

Note that, by default, port forwarding will work only for local connections to ssh. If you want other computers on the local network to be able to use the secure link, you can specify the -g option on the ssh command line.

Administrators who wish to disable port forwarding on the server side can set AllowTcpForwarding no in their sshd_config; however, as the sshd_config manual page notes, as long as shell access is provided to users, they have the ability to install their own forwarders if this is disabled.

 

X11 forwarding

While the X11 protocol is based on TCP, it incorporates an authentication mechanism that involves the exchange of hostnames, so that e.g., running an application off a remote machine and expecting it to show up on your screen would not work, since the application would want to connect to its localhost (the remote computer), while your display would expect it to provide the correct host name for the computer. There are also other issues involved. For this purpose, SECSH implementations are frequently able to forward X11 connections as a special case.

Appropriately-configured on the server and client sides (via sshd_config set X11Forwarding yes to allow ssh clients to forward X11 connections and, optionally, ssh_config on the client side set ForwardX11 yes), the SECSH server will set up a "virtual" UNIX domain socket for communication with applications running on the server and create an X11 authentication cookie, etc., and essentially forward X11 traffic along the encrypted connection. As far as your display server is concerned, ssh is creating all those windows; as far as your applications are concerned, they are displaying on the "display server" sshd. (In order to set up the authentication correctly, sshd requires xauth to be present on the remote end, where applications are to run.)

ssh is invoked with the -X option to turn on X11 forwarding. (This option can be omitted if ssh_config is configured to allow X11 forwarding by default, as shown above.) Note that by default, the OpenSSH server is configured to deny X11 forwarding attempts.


scp and sftp

scp is meant to be a secure alternative to the traditional rcp utility; as such, it provides the ability to transfer single or multiple files to or from SECSH servers.

[ amitg @ athena | ~ ] scp -r amit@arslinux.com:ars/linux.ars .
Enter passphrase for key 'amitg@athena.localdomain':
.
.
.

There is also the ability to use an interface not dissimilar to a command-line FTP client called sftp.

[ amitg @ athena | ~ ] sftp amit@arslinux.com
Connecting to arslinux.com...
Enter passphrase for key 'amitg@athena.localdomain':
sftp> 
.
.
.

We are sure you will agree that the SECSH protocol and its implementations (in particular, OpenSSH) are remarkably versatile and can likely be considered the Swiss Army Knives of secure communication and tunneling.

 

Cool App of the Week

As Scalable Vector Graphics (SVG) become more popular on user desktops and the web, the need for drawing tools has increased. One of these newer tools is called Inkscape. We really like Inkscape's User Interface. It only takes a few seconds to start drawing and manipulating objects:

Image:Inkscape.gif

A simple example of an SVG logo

Of course, a larger gallery of examples will give you a better idea of what is possible with Inkscape. One of SVG's greatest strengths is that it is XML, so we can look at the resulting file from our example and see how Inkscape saved our drawing into SVG.

As you can see with a simple example you can follow along and see how the XML is interpreted into a picture. This is why SVG is an attractive solution for many web- and data-driven desktop applications.

Inkscape itself is still in its infancy, but is rather stable and useful for those that need to quickly generate SVG images.

 

/dev/random

This article is in need of attention.

Please improve it and then remove this notice.

Missing Links.