Traditionally, access to the shell was by rsh', rlogin', telnet' and other services. With widespread use of and access to Unix, it has been shown repeatedly that these services are often compromised. A popular replacement of these services, which offers much greater security, is the secure shell service, or ssh'. This offers encrypted shell access between two hosts across a network. To run this service, the ssh daemon (sshd) and the ssh client (ssh) are required. The package can be downloaded from ftp://ftp.cs.hut.fi/pub/ssh. As of writing, the latest version is 2.0.13.
Installation is standard and, given documentation, shouldn't be a problem. Once installed and executed, sshd runs in the background. The daemon should be executed at boot time by adding the execution command to the boot scripts (as discussed last month).
The ssh daemon, once executed, acts as a super server', i.e., it binds' itself to the port (in this case, port 22) and deals with incoming traffic (in more complicated setups, it can also handle outgoing traffic). The super server takes care of the authentication, encryption and other jobs involved in interfacing to a network. When a remote ssh client connects to the daemon, it launches a child process, which is in charge of interfacing the remote client to the shell.
The configuration file for the server can be found at /etc/ssh/sshd_config. Most of this information you will not find too intriguing, but the rules DenyHosts and AllowHosts could prove useful.
Restricting remote host access
In the case that remote hosts try to compromise your secure shell service, now that you have opened a port to the network, you can block their access to it. This is done based on domain, host or IP matching. This type of filtering is by exclusion, meaning that all hosts are allowed except those listed. There are some drawbacks with this DenyHosts method, for, potentially, there will always be new hosts trying to access the port and compromise security. Indeed, it is often the case that one person tries to connect to a remote machine from many different machines, in the hope of compromise by sheer force. In this scenario, more hosts would have to be continually added to the list.
Alternatively, if you want only trusted hosts to connect to your machine and potentially access the shell, you can use the AllowHosts rule, which is a rule to filter based on inclusion. Only the hosts or addresses which match the pattern included in the list will be allowed . This method, while extremely secure, has its drawbacks. Each time you want to allow a person with a host which does not match your rule for hosts, you must add their host to the list.
If sshd is running in the background, and the configuration file is updated, sshd must be forced to re-read it. This is done using the kill' utility. Sending the sshd process the HUP (Hang UP) signal achieves this. To do so, you must find the process id (pid) of sshd, using pidof sshd'. If it returns nothing, sshd isn't running (did you execute it? is it in the boot scripts?). If it returns a number, that is the pid you want. It is possible that pidof' will return several numbers (when there are remote connections active). It will be fine to send the HUP signal to these processes, too. The final command will be kill -HUP
Of course, you could choose to allow all hosts (by leaving AllowHosts and DenyHosts commented out of the configuration). This will still be a secure service. When it comes to security, however, one should be as thorough as possible.
By now you should have a secure shell being accessed on your machine by remote hosts. To test the service, you should try to connect locally. That is, by running ssh localhost'. You will be prompted for a password, that of the user as which you are running ssh. If you are logged in as jack' and want to login via ssh as jill', you should run ssh -l jill localhost'. Further information on the functionality of the ssh client (and it is vast!) can be found in the ssh manual.