Every time we telnet into a remote machine the connection data will cross the local network, giving an eventual intruder the possibility to spy the connection and eventually insert some malicious commands into the data flux. The use of some strong cryptography systems will allow an enormous improvement in the security of the net.
From the manual page of ssh we can learn that: "Ssh (Secure Shell) is a program for logging into a remote machine and executing commands in a remote machine. It is intended to replace rlogin and rsh, and provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel". It is a powerful, very easy-to-use program that uses strong cryptography for protecting all transmitted confidential data, including passwords.
At present time there are two SSH protocol, referred as SSH2 and SSH1, the first one being an improvement of the SSH1 protocol. SSH2 now supports other key-exchange methods besides double-encrypting RSA key exchange. The current distribution comes with Diffie-Hellman key exchange and has support for DSA and other public key algorithms besides RSA.
SSH2 can be compatible with SSH1, but it is not compatible by default; the SSH2 server alone can't manage a SSH1 connection and a SSH1 server must be in place in order to do that.
You can obtain SSH2 & SSH1 clients and servers from the master FTP server, or from its mirrors. The last version of SSH1 protocol is ssh-1.2.30.tar.gz, while for SSH2 you can download ssh-2.3.0.tar.gz.
The installation process is really easy. The first step is unpack your SSH1 sources:
tar -zxf ssh-1.2.30.tar.gz
This will create a directory ssh-1.2.30. Now go into that directory and start the configuration process:
cd ssh-1.2.30 ./configure
The configure script carries out all the configuration needed in the compiling stage, searching the system for the required library and programs. When the scripts end its job you can start the compilation:
After the compilation stage, become super-user and install binaries, configuration files, and hostkey by typing:
This will normally install clients (scp1, ssh-add1, ssh-agent1, ssh-askpass1, ssh-keygen1, ssh1) to /usr/local/bin, and a server (sshd1) to /usr/local/sbin. Notice that, in /usr/local/bin there are also symbolic link (without the trailing "1") to the real executables.
The next step is to install SSH2. The operations needed are the same required by SSH1:
tar -zxf ssh-2.3.0.tar.gz cd ssh-2.3.0 ./configure makeand as a super-user:
In the following part we suppose you have either SSH1
and SSH2 installed.
In order to make the SSH2 server able to manage a SSH1 connection you should edit SSH2's configuration files, which are normally placed in the directory /etc/ssh2/.
In that directory edit the file sshd2_config, the configuration file for sshd2 (Secure Shell Daemon) which is the daemon program for ssh2. Add the lines:
Ssh1Compatibility yes Sshd1Path /usr/local/sbin/sshd1
Obviously modify the information /usr/local/sbin/sshd1 to agree with your sshd1 installation directory. With this configuration, sshd2 server will forward requests from SSH1 client to sshd1.
Then add two lines to the file ssh2_config, placed in the same directory:
Ssh1Compatibility yes Ssh1Path /usr/local/bin/ssh1
now ssh2 client will invoke ssh1 client when contacting a SSH1 server.
There are mainly two different techniques to start sshd at boot time.
Go into /etc/rc.d directory, and edit the file rc.local. At its end add the lines:
echo "Starting sshd ...." /usr/local/sbin/sshd
In such a way, at the end of your next computer reboot, sshd is invoked and the message Starting sshd .... is printed on the screen. To start sshd without rebooting the machine type from the command line:
id:3:initdefaultIn the first case your runlevel is 5, in the second one it is 3.
In the directory rc$number.d issue the command:
ln -s ../init.d/sshd2 S90sshd2Then change directory to /etc/rc.d/rc0.d and run the command:
ln -s ../init.d/sshd2 K90sshd2Repeat the operation in the directory /etc/rc.d/rc6.d.
After doing that you can start sshd2 with out rebooting the machine, simply running the script:
Once sshd is running on your machine you can test your configuration trying to login into it using the ssh client. Let's suppose that you machine is named host1 and your login name is myname. To start a ssh connection use the command:
ssh -l myname host1
In such a way ssh2 client (default client) tries to connect to host1 port 22 (default port). sshd2 daemon, running on host1, catches the request and asks for the myname password. If the password is correct it allows the login and open a shell.
Ssh allows another authentication mechanism, based
upon authentication keys, a public key cryptography
method. Each user wishing to use ssh with public key authentication
must runs ssh-keygen command (without any option) to create
authentication keys. The command starts the generation of the keys
pair (public and private) and ask for a passphrase in order to protect
Two file are created in the $HOME/.ssh2/ directory: id_dsa_1024_a and id_dsa_1024_a.pub, the user private and public key.
Let's suppose that we have two accounts, myname1 on host1 and myname2 on host2. We want to login from host1 to host2 using ssh public key authentication. In order to do that four steps are required:
# identification IdKey id_dsa_1024_a
This file is used by sshd to identify the key pair to be used during connections.
From host2, get the ssh host1 public key and rename it in a suitable way (e.g. host1.pub):
ftp host1 [...] cd .ssh2 get id_dsa_1024_a.pub host1.pub
At the end of ftp process a copy of host1 public key, named host1.pub, resides in host2 $HOME/.ssh2 directory.
# authorization Key host1.pub
This file lists all trusted ssh public keys placed in $HOME/.ssh2 directory. When a ssh connection is started from a user whom public key matches one of the entry of authorization file the public key authentication scheme starts.
In order to test the previous configuration, you
could try to connect from host1 to host2 using ssh. Sshd must reply
asking for a passphrase, otherwise, if password is requested, some
mistakes occurred in the configuration process and you must check
carefully steps 1 to 4.
The passphrase required is your LOCAL passphrase (i.e. passphrase protecting host1 public key).
The next article will present other programs and facilities from ssh suite: ssh-agent and ssh-add (two useful passphrase management programs), and sftp and scp (a secure way to transfer files across the net).