Home  |  Map  |  Index  |  Search

Convert to GutenPalm or to PalmDoc by Georges Tarbouriech About the author: Georges is a long time Unix user (commercial and free). He is very interested in security and wants to thank the free software community for the great job done in this area. Content: Why use ssh ? SSH and VNC SSH and MySQL SSH and terminal emulation Where to go from here ? At least, it's over ! Talkback form for this article

Through the tunnel

Abstract:

SSH, the secure shell, is a very good commercial product. However, there are various great free implementations of ssh clients or servers available for Unix (commercial or free) or for different OSes.
The best known is OpenSSH, available from http://www.openssh.org. From this website you can find alternatives for Unix systems, Windos, Mac... For some products such as Windos you only have free clients.
In this article, we present a few examples on how to use ssh to tunnel data from/to external applications. VPN (Virtual Private Network) relies on ssh but in a different way, much more elaborate than the one we take up here. Another sophisticated solution, is to use VTun.
Accordingly, let's consider this tunneling an easy and simple way to encrypt data in an heterogeneous network to prevent it from being snooped. Obviously, this is applicable to both local and remote networks. However, remember ssh only encrypts data, it won't make your network secure on its own...
You've been warned !

Why use ssh ?

SSH is a replacement for telnet or rsh, rlogin, as already mentioned in a previous article. Even if some security problems were found recently in ssh, it remains a good security tool for data encryption. By the way, the above mentioned security problem concerned passwords : it's strongly recommended to use passphrases instead and of course RSA keys ! Using ssh doesn't prevent you from using many other security tools such as tcpwrapper.
It's quite easy to snoop data circulating through a network with standard tools such as tcpdump or snoop. You can test this on a network where two machines are exchanging data using telnet, for instance. From a third machine running Linux, for example, run tcpdump (as root, obviously) and see what happens. You can read all the data ! (Editors note: the three computers need to be connected via a hub to test this. It will not work if you have a switch but the point is still valid.)
Of course the display is too fast to be read on the screen, but nothing prevents you from redirecting the output to a file and then to be able to read it while drinking a coffee. If this is true for the data, it's true for the password : that is, the door is wide open to the crackers. You give them the key to your house.
Just imagine if the circulating data is confidential... If you're the sysadmin, I'm afraid your boss will ask you to get another job somewhere else.
The remote commands, rsh, rcp, rlogin are very dangerous too, since the data is not encrypted either. If ssh is a good replacement for rlogin or rsh, it comes with scp being another good replacement for rcp. That is, you don't need anymore remote commands or telnet if you use ssh, at least, you shouldn't use them.
How to install ssh, how to generate private and public keys... is not within the scope of this article. You'll find everything you need within the ssh archive you download or by reading the documentation available on the matter from the Linux Documentation Project.
Since using a computer today almost always transfers data in one way or another, ssh should be compulsory... well, it's up to you. However ssh can do much more than replacing telnet or the remote commands.
It can be used to encrypt the data transferred between external applications and obviously between different OSes. It can also compress this data. It's often used with protocols such as pop, ftp, http... either for compression or encryption. This is very useful, if you are a sysadmin, for instance, to connect from home to work or vice versa.
Being a client/server application, ssh obviously needs both to work : you need a machine running an ssh server and a machine running an ssh client (I hope you noticed how smart I am !).
Why am I insisting on this obvious fact ? Because, since we are talking about free software, many OSes apart from Unix don't have free servers. That is, sometimes you won't be able to do the obvious, you'll have to turn the problem around : the key is called forwarding. More on this later. That means, using OSes such as Mac OS or Windos implies you don't have free servers so you will have to manage with clients alone. How to do so isn't always that obvious. Let's take a few real examples.

SSH and VNC

If you don't know VNC, you're missing one of the greatest tools ever. You can have a look there to learn more about it.
If you go to the VNC website at http://www.uk.research.att.com/vnc/docs.html you'll find a lot of documentation concerning what we are talking about. For instance, you'll find how to use VNC through ssh, from a Windos ssh client to an Unix ssh server. Accordingly, I won't rewrite Frank Stajano's great work since it's much better than what I could do.
So, let's see how this can work.
First of all, you have to choose a free Windos client. For this example, we'll use Teraterm Pro with its Ttssh extension. You can find it at http://hp.vector.co.jp/authors/VA002416/teraterm.html. As a matter of fact, it's called Ttssf, since it's a version allowed in France. (Things are changing, but be aware many countries don't accept encryption yet. Check this URL to see the encryption situation in you own country : http://www2.epic.org/reports/crypto2000/countries.html.)
Now, let's say you launched an ssh server on an Unix machine. On the same machine, we suppose you can run a vncserver. Once those two servers are running, you can connect an NT machine to a Unix server using Ttssh. That means you now have an encrypted connection between the two machines. But this doesn't allow you to run an encrypted vncviewer protocol (vncclient) from that NT machine. To do that you need to tell ssh to forward (there we are !) the right port.
The Unix machine running the vncserver is called "bandit" and uses the port 5901, because it's the display number 1, the default X display for this machine being 0. The normal use would be to send a command "vncviewer bandit:1". This will work, of course, but without the data being encrypted. Instead, using the NT "shell" (that's to say the DOS interface...) , send the command "/ssh-L5902:bandit:5901" without space. This means, you create a local port 5902. Now a command such as "vncviewer localhost:2" runs an encrypted connection of the VNC protocol on your NT machine. This can be done without using the command line since Ttssh has a graphical interface. Let's add this syntax only concerns Ttssh. Typing the same command from an Unix machine should say : "ssh -L 5902:bandit:5901 bandit".
This is of course a basic example : you can do much more complex things. Check the documentation available from VNC website, especially the one from Frank Stajano.

SSH and MySQL

MySQL is probably one of the most used DBMS, especially on the Internet. Again, securing MySQL is out of the scope of this article. However, encrypting the data circulating between a MySQL server and a MySQL client makes the connection more secure. SSH allows you to do that, in the same way as we did it with VNC, that is port forwarding.
Let's say our example concerns an Intranet. The MySQL server is a Linux box and most of the clients are NT machines. Once again, we use a Ttssh client on the Windos machines.
The default MySQL port number is 3306. Then we forward the same port (3306).
You can do either a local forward or a remote forward.
A local forward will look like "/ssh-L3306:localhost:3306" on the NT machine or "ssh -L 3306:localhost:3306" on a Unix machine. Using "localhost" allows sending the data through the loopback interface instead of the host interface.
A remote forward would be "/ssh-R3306:bandit:3306" for NT and "ssh -R 3306:bandit:3306" for Unix.
This only concerns the connection itself. To log into the DBM, you obviously need to set your hostname and your username for the MySQL server, probably different from the login username for your machine. Investigate the ssh man pages about option "-l".
Of course, this will work only if you have a MySQL client on your NT machine.
If you don't, you will need to use an ODBC application, Sybase for instance. Start this application and use your ODBC driver to link it to MySQL. You can now connect to the localhost not to the MySQL server host, to access the MySQL server. The data circulating between the server and the client is now encrypted. You can check it with snoop or tcpdump.
That's a local network example. If you feel like doing such a thing on WANs, it should be a bit more complex, if you're behind a firewall. This can be a way to do some remote administration from home if you're the sysadmin, but you can't expect to use such a method to access a DBM on a website. You then will have to look for something much more sophisticated, like VPN for instance, but this is the idea.
Anyway, don't believe that's enough to set a secure DBM server transferring confidential data such as credit card numbers ! And, by the way, who really believes someone saying he has a very secure server able to transfer this sort of data without any risk ? Personally, I don't !!!

SSH and terminal emulation

What does this mean since we are already using terminal emulation ?
Let's say you run an old Cobol application on a Unix server. The clients are, again NT machines. To connect they need a more sophisticated terminal emulation than vt100, vt220 or vt320, since they have to get the proper user interface. That is, accents, tables... Setting a standard (vt100, vt220...) terminal emulation to 8bit won't work properly. What you get is just unusable. Accordingly, since it's a rather old product, you use an "old" terminal emulation specific software.
After a long fight trying to get the right emulation, you find "ibm3151" gives the best result. So far so good !
But, since the software you use has been developed many years ago, it doesn't know anything about security. The connection uses telnet ! As a matter of fact, the data transferred is quite confidential... So what ? You have to find, at least, a way to encrypt the data. And again, ssh will help.
Once again, There Is More Than One Way to Do It...
Either you redirect telnet to port 22 (ssh) or you forward the port of the terminal emulation. But... I'm afraid the server won't accept a normal user redirecting the telnet port (default is 23) : you must be root to do such a thing (at least I hope !). Concerning the terminal application, it can be used by different users at once, thus using different ports for each connection, i.e, 10 users=10 ports.
That's becoming a bit tricky, isn't it ?
So, first of all, the application server must have the ssh server running and listening to port 22.
>From an NT client, connect to the app server either using Ttssh or the "command line". That is you establish a secure connection between the server and the client as a specific user. From the Ttssh options you forward the local port 50000 to the port 23 (telnet) on the remote server. From the command line, it should look like "ssh-L50000:servername:23". Now you can tell your terminal emulation to run through port 50000 instead of port 23. The data now circulates through a secure channel, that means encrypted. You can check it with snoop or tcpdump.
Obviously, you should do the same for each client allowed to connect to the application, changing the forwarded port number. For example, you could use 50001, 50002, and so on.
Now, you could ask : why such high ports ? The answer is : for many reasons !
Seriously, the main reason is that you can "manipulate" high ports without being root.
The second reason is that the selected port must not already be in use on both machines. Example : if the server runs Solaris, many high ports are used, according to the running services. Thus port 50000 and up should work. That means you'll have to check the ports in use before forwarding.
Of course, this would work for many other OSes able to use ssh clients.
Concerning the way to automate the process on the clients machines, it's up to you. You can't ask a "normal" user to do all this before connecting, can you ? Then, we leave that as an exercise for the readers...

Where to go from here ?

Those few examples show the numerous uses of ssh. You can do much more with a lot of applications and ssh. It depends on your needs. However the "philosophy" is almost always the same : port forwarding.
Nevertheless, be careful when using more complex forwarding. For instance, if you forward through a third machine, the data circulating in the middle connection won't be encrypted.
Another drawback concerns Windos clients using Ttssh. The connection to forwarding ports relies on IP addresses like remote commands do, thus allowing spoofing attacks. Hence the need to use other tools besides ssh, such as tcpwrappers.
Investigate the "literature" about ssh, it will teach you a lot. Your imagination will do the rest.

At least, it's over !

Security should be a concern for everyone, but it isn't ! ssh is only one of the security tools you can use everyday. It's quite a good one, as soon as you consider it for what it is, that is an encryption or compression tool.
On its own, ssh is almost useless, since it won't solve the numerous "holes" you can have in a machine or a network. Securing a host, or a network, is a big job and tools don't make everything even if they are quite good.
The basic tasks are compulsory when it concerns security. Don't forget to remove all the unused services, check the SUID root programs, disable the "risky" programs... There's a lot to do and it will never be enough. You can install all the available security tools, it will be useless if you leave one or more backdoors wide open. Of course, this is another story, but don't forget the obvious.
Going back to ssh, let's say it is a tool you can't live without, as soon as you use it properly and for what it has been made. Again, use it with passphrases and RSA keys, not with passwords. Check the permissions of the different files in the .ssh directory and of course the permissions of the directory itself. And again and again, at least use wrappers !
However, remember, you can tunnel through ssh most of the existing protocols. This can be quite useful to make connections a bit more secure.
There is another common use of ssh we didn't talk about, X session forwarding. Since this implies running X on different OSes, we intentionally left it off. But it's well within the scope of protocol tunneling. X not being that secure, ssh can make things better.
For more sophisticated use, ssh won't be enough. As we said before, check VPNs or tools like VTun, they probably will help a lot.
Last but not least, check the encryption situation in your own country. It would be sad to go to jail as a spy just for using a software like ssh.
It's like that...
Anyway, we're living a in great time !  

Talkback form for this article

2001-05-01, generated by lfparser version 2.13

mirror server hosted at Truenetwork, Russian Federation.