![[Photo of the Author]](../../common/images/Georges-Tarbouriech.jpg)
original in en Georges Tarbouriech
en to en Lorne Bailey
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.
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 !
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.
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.
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 !!!
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...
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.
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 !