ssh: Secure Shell
The ssh program suite is an interesting way to establish a secure communication channel between hosts across the Internet. It replaces a few usual communication channels (such as telnet, rlogin, rsh and rcp) and provides equivalent functionality via a new secure protocol. This article is meant to introduce the user to ssh features without any pretense of being an authoritative tutorial on security issues.
First of all, as usual with encryption material, let's throw in some legalese. The Unix implementation of the package is distributed free of charge for non-commercial use and can be retrieved from major ftp sites around the world. The meaning of “non-commercial use” is well stated in the COPYING file within the ssh distribution. Non-commercial use includes use of the tool by people who work on the Internet, provided ssh is not used as a selling argument. However, being allowed by the license is not enough to use the package. You must also ensure your government allows using cryptographic material: some countries prohibit citizens from using any type of cryptography.
As far as standardization is concerned, the IETF (Internet Engineering Task Force) is working on the ssh idea. This means that the protocol is going to be standardized and will always remain throughly documented. Anyone can reimplement the software and distribute her version with different copying policies. Although there is no RFC about ssh yet, three Internet drafts are already available which document the different aspects of the protocol. The drafts I downloaded in June are going to expire on September 1, 1997, but new drafts (or a real Request For Comments) will be released before that time.
The main aim of ssh is overcoming the security problems of TELNET and rsh-like protocols. These protocols, though widely used, are very weak as far as security is concerned: TELNET transmits clear-text passwords over the network, while rsh and friends are easily broken by spoofing techniques (skilled system administrators or anyone with physical access to the wire can exploit the .rhosts files to be granted access on remote computers). These vulnerabilities are addressed by the ssh protocol by enforcing a strong authentication scheme between the communicating parties.
The protocol not only authenticates the client host with the server, but also enforces encryption of all the data sent through the established communication channel. Although encryption requires some computational load in the communicating hosts, the user can be confident that no sniffer can make sense out of network packets, and nobody can forge packets to be granted access with the server.
Finally, the protocol is designed to allow encapsulation of other communication channels within an ssh stream, so that non-encrypted protocols can benefit from ssh capabilities at no cost. This feature is most useful for establishing secure X11 connections, but its use is much more flexible than just that security.
As far as the user interface is concerned, the new programs are designed as drop-in replacements for rsh, rlogin and rcp. While the system administrator needs to deal with the ssh issue at least to install the package, the final user can happily ignore the fact that the underlying communication mechanisms have been changed.
The current version of ssh, as I'm writing this article, is 1.2.20. It is distributed with a configure script, so that:
./configure && make && make install
does the complete job of installing the package. Even if /usr/local belongs to you, you'll need to be a privileged user in order to install ssh. This requirement is necessary, because both the server and some client programs must be able to open privileged TCP ports. Moreover, the package installs its system-wide files in the /etc directory. If you must run an ssh session without installing the programs as a privileged user, you should first read the FAQ file, which describes how to accomplish this without too much trouble.
The program suite is made up of a server program, a few clients and a pair of support tools. In order to become an ssh server, the suggested action is to invoke sshd from your initialization files when the computer boots. The program is installed by default in the /usr/local/sbin directory, and it listens to port 22/tcp of the local host to accept incoming connections. You should add a line like the following one to the /etc/services file, if it is not already included:
ssh 22/tcp # secure shell
It is possible to run sshd from /etc/inetd.conf, by passing the -i flag to the daemon. This practice is discouraged, because the daemon can take several seconds to start, as it generates an encryption key each time it starts.
On the client side, nothing needs to be done at installation time to enable use of the services. After installation, several programs can be found in the /usr/local/bin directory that can be executed by anyone. Here's a list of these programs:
ssh (slogin): The ssh client program behaves like rsh in that it executes a command on a remote host, redirecting its own stdin, stdout and stderr to the remote. If only one argument is specified in the command line, it is taken as the remote host, and ssh opens a terminal session on that host, just as rlogin does. The slogin client is just a symbolic link to ssh. Usually, the user is asked to provide a password for authentication on the remote host.
scp: “Secure CoPy” is a replacement for “Remote CoPy”. It uses the same syntax and performs the same task, with the same security enhancements offered by ssh. The user is usually prompted for a password to perform authentication.
ssh-keygen: This program generates new keys associated to the user who invokes it. The public key and the private key generated are saved by default in the directory $HOME/.ssh/, in two files called identity and identity.pub. A pair of keys is needed, when you wish to securely log into the local host from outside without providing a password.
ssh-agent: This program is meant to manage security for a user session. It stores the private keys for the user and can be contacted by any child process. See the man page for more information about ssh-agent.
ssh-add: This program adds identities to the authentication agent. ssh-agent must be an ancestor of the process running ssh-add in order for them to communicate.
ssh-askpass: This short program is used internally by ssh-add and ssh-keygen to ask for a pass phrase using the X graphical environment.
make-ssh-known-hosts: This PEl script retrieves the public keys of all hosts in a domain; it queries the DNS and talks with hosts belonging to a domain. This program updates the /etc/ssh_known_hosts file to hold the new keys. The program should be run periodically, usually via cron, to reflect any change in host public keys or new installations of ssh on hosts in the local networks.
Although the number of installed files might scare a novice user, there's nothing new to learn as long as you just use the plain ssh and scp client programs. The system administrator can even choose to replace ssh for rsh and scp for rcp, so that secure operation is completely transparent to the final user. Actually, such a replacement is not completely transparent, since ssh introduces a new feature not present in plain rsh or rlogin: X11 forwarding. This feature is considered a “side effect”of using the ssh protocol and is described in the next section.
The role of the other programs is secondary. They help to set up a good working environment to avoid typing too many passwords during normal operation without compromising system security. While knowing their internals is not essential for program operation, a quick look over the documentation might provide interesting insights about current encryption technology and can help in configuring hosts to automate the login process.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Android Candy: Intercoms
- Return of the Mac
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Designing Foils with XFLR5
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis
- Consent That Goes Both Ways