|
Project: Linux  Howtos
Replacing Telnet; OpenSSH, a secure alternative
By Mayank Sarup <mayank@freeos.com>
Posted: ( 2000-11-21 07:34:46 EST by mayank )
The Internet was originally designed as a research and educational
resource and the technology that today forms the backbone of the
Internet is largely based on that philosophy. However as time has
gone by, security has become an important issue on the Internet and this
article looks at implementing more secure versions of common Internet
applications.
The Internet is built with communication in mind. You will routinely move
around the Web from one site to the other or telnet to another machine to
check your mail or to administer that machine. The trouble with most of
these protocols is that they are not encrypted. Over a telnet connection,
your passwords are sent as plain-text, which can be read by anyone.
Using sophisticated programs called packet sniffers, even a amateur hacker
can spy on your connection and grab your data. Secure Shell (SSH) was built to address these faults and provide a more
secure environment to work in. SSH encrypts all your traffic including
your passwords when you connect to another machine over the net. SSH also
replaces telnet, ftp, rsh, rlogin and rexec. Let's take a look at OpenSSH, an excellent and more importantly open
source implementation of SSH. It is very well supported by the OpenBSD
team and includes rock-solid SSH2 support. Versions are available for
nearly all the Unices including Linux, which is what we are using here. OpenSSH can be downloaded from www.openssh.com. The latest version as of
writing this article is 2.3.0. It is available as source tarballs
or in RPM format. If you are downloading the RPM's, then you need to get
the following files. openssh-2.3.0p1-1.i386.rpm
openssh-clients-2.3.0p1-1.i386.rpm
openssh-server-2.3.0p1-1.i386.rpm Zlib - This is an open source and patent free lossless data compression
library. This should already have been installed as part of your standard
Linux installation. If not then you can download it from
http://www.freesoftware.com/pub/infozip/zlib/. Source is available as
also RPMs. Take your pick. OpenSSL - Another open source effort, aimed at creating a commercial grade
toolkit implementing Secure Socket Layer (SSL), Transport Layer Security
(TLS) and a strong cryptography library. This is also available as source
or RPM packages. The RPM packages are available right where the OpenSSH
RPMs are. The source packages are available at www.openssl.org Installation Zlib RPM: rpm -ivh zlib-1.1.3-i386.rpm For the tar.gz tar zxvf zlib-1.1.3.tar.gz
cd zlib-1.1.3
./configure
make
su -c "make install" OpenSSL RPM: rpm -ivh openssl-0.9.5a-i386.rpm For the tar.gz tar zxvf openssl-0.9.5a.tar.gz
cd openssl-0.9.5a
./configure
make
su -c "make install" OpenSSH RPM: rpm -ivh openssh-2.3.0p1-1.i386.rpm <- Should be installed first
rpm -ivh openssh-clients-2.3.0p1-1.i386.rpm
rpm -ivh openssh-server-2.3.0p1-1.i386.rpm For the tar.gz tar zxvf openssh-2.3.0p1.tar.gz
cd openssh-2.3.0p1
./configure --sysconfdir=/etc/ssh By default OpenSSH places the configuration files under /usr/local/etc. Using
the --sysconfdir allows you to set your own. make
su -c "make install"
su -c "make host-key" This will create the RSA and DSA host keys for your system. SSH works on
the public/private key pair method. RSA is the older format whereas DSA is
the new format and the one used by SSH2. Enter the contrib sub-directory. There are a few files of importance here.
First is ssh.pam.generic. Most new Linux distributions use PAM for
authentication. This is a generic file that suits most distributions. A
version for Red Hat can be found in the redhat sub-directory. Copy this
file to /etc/pam.d as sshd. cp sshd.pam.generic /etc/pam.d/sshd Also provided here are init script for use with SuSE and Red Hat. The SuSE
directory also contains a configuration file that you should copy to
/etc/rc.config.d cat rc.config.sshd >> /etc/rc.config You can use these scripts across most distributions with a few changes.
One of the changes that we needed to make to the SuSE script was to change
the path from /usr/sbin to /usr/local/sbin. Copy the startup script to
/etc/rc.d/init.d (Red Hat) /sbin/init.d (SuSE). Now you can start the ssh daemon by /etc/rc.d/init.d/sshd start (Red Hat) or /sbin/init.d/sshd start (SuSE) To check whether SSH is running, telnet to port 22 on your machine. You
should see the following. Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-1.99-OpenSSH_2.3.0p1 Usage First thing that each user needs to do is create a public/private key
pair. This is done using the ssh-keygen program. ssh-keygen -d The command ssh-keygen is enough to prepare an RSA key for usage. The '-d'
bit makes a DSA key instead for use with SSH2. You will be asked for the
filename to store the key as. This allows you to have different
private/public key pairs for the various hosts that you will be connecting
to. The private key will saved as the file you specify in
$HOME/.ssh/filename (Default: 'identity' for RSA keys and 'id_dsa' for DSA keys) and your public key will be stored with the '.pub' extension added
to it. You will also be asked for the passphrase, which is used to
encrypt the private part of your key further. You could do without
one but for those paranoid about security, this is a must. Ssh is quite easy to use. As a replacement for telnet, it has a myriad of
options and is very flexible. ssh hostname This is the most basic usage - Making a secure connection to a host. If
this is the first time that you a connecting to the host, you will be
prompted by the following message The authenticity of host 'hostname' can't be established.
RSA key fingerprint is 3b:60:57:4e:6c:59:5a:99:cf:41:d5:e0:14:af:0d:a1.
Are you sure you want to continue connecting (yes/no)? Type a full 'yes' to add the host key to your list of known hosts. These
are stored in a file under $HOME/.ssh/known_hosts. You will then be prompted for the password after which the connection proceeds.
A better command-line that you are likely to use is
ssh -C -i identity_file user@host [command] -C - Use compression. Definitely a very good idea over a modem link. -i - If you are using multiple public/private keys for various hosts, you
need to specify the one to use for the current connection. This should
point to the private key to be used. user - The user you want connect as. host - The host you want to connect to. command - This is the command to run after connecting. You can use this to
directly run a command off the host you are connecting to. If you would like a lot more information as the connection progresses, you
can add a '-v' to put ssh into verbose mode. SSH also provides you with a way to connect to the other host *without*
using passwords. Just copy your public key file, whether RSA or DSA, over
to the server that you will be connecting to. On the server, you then need
to add this to the file $HOME/.ssh/authorized_keys (RSA keys go here) or
to $HOME/.ssh/authorized_keys2 (DSA keys go here). Now just run the normal
SSH command and you should will directly enter your home directory on the
server. You will probably be prompted for the password the first time but
thereafter you can connect without entering your password. Secure File Transfer Ssh also provides you with a secure way to transfer your files over the
Internet. The program to use here is scp (Secure Copy). Scp syntax is also
very basic. scp user@host:filename user@host:filename To copy a local file to another host using ssh scp freeos.gif mayank@foo.com: This will copy the file freeos.gif in the current directory to user mayank
at host foo.com. The ':' at the end of the destination is required because
otherwise scp will copy the file to one named mayank@foo.com. To copy from a remote host to your local directory scp mayank@foo.com:freeos.gif . This will copy the file freeos.gif from user mayank's home directory at
foo.com to the local directory. There is also a '-r' option for recursive copying of files across directories. User configuration The default OpenSSH configuration will work for everyone. You will find
the system wide configuration files in /etc/ssh or if your left it at the
default, in /usr/local/etc. There will be two configuration files here,
ssh_config and sshd_config. The file ssh_config set's the options for the
ssh client program that you will be using. The second file, sshd_config is
the SSH daemon configuration file. The configuration file for ssh only set the default options for itself.
When a user runs ssh, it first looks at the command line options,
$HOME/.ssh/config followed by /etc/ssh/ssh_config. This allows a user to
put in his own options. The format of $HOME/.ssh/ssh_config is quite simple. There are quite a few
options here but not all are required. A simple host entry would be host foo
compression yes
DSAAuthentication yes
hostname ssh.foo.com
user foo2
IdentityFile [filename] Each section in the config file starts with a "host" line. Wildcards (*
and ?) are allowed here. A "Host *" would mean that the configuration
below is to be used for all hosts. "Host *freeos.com" is also a valid
entry. Compression is a good option to give here. In addition to an encrypted
connection, you can also choose to compress the data. This is great over
slower modem links. An additional parameter that you can give after this
is "CompressionLevel". Possible values for this are 1 thru 9 with 1 being
the least level of compression and 9 being the most compression. DSAAuthentication specifies that you would like to use the more secure DSA
method of authentication. Hostname parameter should be set to the host that you are trying to
connect to. This is only required if you are using the "Host" parameter as
an alias to Hostname. Here I am using foo as an alias for ssh.foo.com.
When I try to connect to foo, I will actually connect to ssh.foo.com. User is the user you want to connect to the host as. IdentityFile should point to your RSA or DSA key. This is useful when you
have to specify different keys for different hosts. If not specified then
$HOME/.ssh/identity or $HOME/.ssh/id_dsa is read. For DSA keys you need to
use "IdentityFile2". Multiple identity files can be specified here; they
will all be tried in sequence. One thing you need to be careful of is to make sure that your
defaults are placed after the host declarations. This is because every
option in ssh is set only the first time. Let's say, we have defined a
default parameter for user in the configuration file. It is set to foo2.
In a subsequent host section, we set the user to foo3. This will cause
problems because ssh first reads the default value of foo2 but when it
comes down to the host section it will ignore the user line because we
have already specified it up ahead in the configuration file. So make sure
that all the default parameters that you use across all hosts come last in
the file. There are a lot more options here and the ssh man page is a great resource
for that. Or, you could always send me a mail.
OpenSSL.org
OpenSSH.com
Zlib
Other articles by Mayank Sarup
Current Rating: [ 8.11 / 10 ]
Number of Times Rated: [ 65 ]
|
