by January 1, 2001 0 comments

Whenever you telnet or FTP (not the anonymous FTP) to a
remote machine, you are asked to identify yourself by giving your login name and
a password. These are then transferred over TCP/IP in clear text. In TCP/IP your
data does not reach the destination machine directly through a single router,
but travels through a number of intermediate machines. This can be a drawback as
any of these intermediate machines can be set to capture the data. Clear text
passwords can thus be easily captured. In this article, we’ll talk about
safety measures against this.

On an Ethernet network, the network card of a machine is
intended to capture only the data meant for it. This can, however, be changed by
using programs called Sniffers. These put the network card in promiscuous mode,
which enables it to capture all passing data. Since the login name and password
go in clear text, anybody can capture it. One solution is to encrypt the data
such that only the destination machine can decrypt it.

The Public Key Infrastructure (PKI) is one technique that can
be used. There’s a package called Secure SHell v2 (SSH) with strong encryption
algorithms that can be used for the task. It lets you generate a public-private
key pair on the local machine. Subsequently, the public key can be transferred
to the remote machine. Unfortunately, the software is not freely distributable
so we couldn’t carry it on this month’s CD. You’ll have to download its
RPM from ftp://ftp.ssh. com/pub/ssh/rpms/. This has to be installed both on the
local and the remote machines.

The software installs several utilities, which include an SSH
daemon (sshd2), the SSH client (ssh2), SSH copying utility (scp2), SSH FTP
server (sftp-server2), SSH FTP client (sftp2), and some key generation and
management utilities. The SSH daemon automatically starts up after the
installation. If it doesn’t, you can start it as:

/etc/rc.d/init.d/sshd start

If you would like the daemon to start automatically on
startup, then type:

ntsysv

From the list of daemons that comes up, select ‘sshd’. It’s
important for the SSH daemon to run on the remote machine. We’ll assume that
you have the same login name on the local and the remote system. They can be
different as well, but the configuration will be slightly different.

Local machine setup

Login to the local machine and type:

/usr/local/bin/ssh-keygen2

This will automatically create a DSA public-private key pair
of 1,024 bits. Subsequently, you’ll be asked for a passphrase (password). You
will be asked this whenever you access the remote machine. The public and
private keys are stored in id_dsa_1024 _a.pub and id_dsa_1024_a files in the
directory named .ssh2 in your home directory. Change to this directory and issue
the following:

echo “idkey id_dsa_1024_a” > identification

This generates a file named ‘identification’ that
contains the name of your private key. It’s consulted every time an SSH
session takes place.

Remote machine setup

Now we move on to the remote machine configuration. Login as
the same user (as on local machine) and execute the ssh-keygen2 command as
before. Now copy the file id_dsa_1024_a. pub from the local machine to the
remote machine by changing its name to .pub or any other name in
the .ssh2 directory found in your home directory on the remote machine. You can
transfer this file via e-mail (if the remote machine is geographically far) or
floppy. Next change to the .ssh2 directory and issue the following:

echo “key .pub” > authorization

Likewise, this also creates a file called authorization that
contains the name of your public key.

Remote telnet

On the local machine, you can start a Telnet like session
using ssh2 command as follows:

/usr/local/bin/ssh2 192.168.1.28

Here, the IP address of the remote machine is 192.168.1.28.
The first time you connect, a message pops up saying ‘Host key not found’.
Ignore it and answer ‘yes’ to continue. This message will not be displayed
again. You will then be asked for the passphrase. Key it in and you’ll be able
to see the shell prompt of the remote machine. It will take you directly to your
home directory on the remote machine. Then you can proceed as you would in a
normal telnet session. You’ll not notice any difference, but under the hood
all data traveling to and fro will be encrypted.

How SSH authentication works

The SSH client on the local machine contacts the ssh daemon–the
server–on the remote machine and tells that a user ‘<user name>’
wants to connect. Now the server checks the authorization file in the .ssh2
directory. If an entry is there for a public key corresponding to the user, the
server generates a random message, constructs an MD5 message digest and encrypts
it with the user’s public key <username>.pub. This is then sent to the
client. The client looks in the identification file for the private key. Since
only the client has the corresponding private key, which is id_dsa_1024_a, it
can only decrypt the message. This results in the message digest. Now the client
computes a checksum of the message digest and sends it back to the server. The
server then computes the checksum of the message digest it had sent to the
client. If this checksum and the checksum received from the client are the same,
then the client can be trusted to have the correct private key, and the
authentication procedure is completed.

Copy files securely

To copy files securely between the local and remote machine,
use the command scp2. Suppose you want to copy a file named secret.txt in your
local home directory to the remote home directory. If the IP address of your
local machine is 192.168.1.5 and you are using the login name ‘shekhar’,
then issue the following:

/usr/local/bin/scp2 shekhar@ 192.168.1.5:secret.txt shekhar@
192.168.1.28:secret.txt

You will be asked for your login name and the passphrase and
subsequently the file will be copied as secret.txt in your home directory. If
you want to copy a file from a directory other than your home, you must give the
full path. Suppose you want to copy a file secret1.txt in /opt directory on
local machine to /opt directory on remote machine, then issue:

/usr/local/bin/scp2 shekhar@ 192.168.1.5:/opt/secret1.txt shekhar@
192.168.1.28:/opt/secret1.txt

Obviously the user must have right to access the local /opt
directory as well as to create files in the remote machine’s /opt directory,
else you get a permission denied message.

Secure FTP

To establish a secure FTP connection to the remote machine,
type:

/usr/local/bin/sftp2 192.168.1.28

This will ask your passphrase and then drop you into a sftp
prompt where you can use the familiar FTP commands like mput, mget, etc.

Secure X

You can use the remote X Window utilities on your local
machine. Fire up X window (by issuing startx). Now connect to the remote machine
using ssh2 as before. With SSH, you don’t need to setup any DISPLAY variable,
used to redirect the display to another machine. Now you can start any remote X
application from the local machine. For example, to see the remote X terminal
window, issue:

xterm &

Or you can fire up the K Text Editor as:

kedit &

All the SSH utilities accept command line options. For more
on these consult their MAN pages. Also the documentation in /usr/doc/ssh<version>
can be read for more customized configuration and a feature called host-based
authentication with SSH.

Shekhar Govindarajan

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.

<