One of the most commonly used utility suites for remote login and file transfer on Unix systems is the Berkeley "r" utilities (rlogin, rsh, and rcp). While being easy to use, they are likewise fairly easy to subvert by compromising a user's account on a weaker system, through the root account on a remote system that trusted by the "r" utilities, by DNS spoofing or IP spoofing, and by packet sniffing attacks. These weaknesses make the "r" utilities a gaping hole in secure administration of distributed systems and are disabled on many systems -- or restricted with TCP wrappers -- for just this reason.
Another excellent facility for leveraging distributed computing -- and a security weakness that regularly gets it banned from traversing secure firewalls -- is the X Window System protocol.
A means now exists to harden these utilities and thus retain all their benefits, while paying just a small cost in network overhead and administrative setup time/energy. That means is the Secure Shell, known as ssh, originally from the Helsinki University of Technology.
Ssh can also be used as a way to "tunnel" other protocols, such as the X Window System protocol, adding encryption to the channel to improve security against packet sniffing and "man in the middle" attacks. When used with X, ssh looks like a normal (albeit a proxy) X server on the local machine which redirects X protocol communication across an encrypted channel to the actual X server on the other end.
How does ssh work?
Ssh works by the exchange and verification of information, using
public and private keys, to identify hosts and users. It then
provides encryption of subsequent communication, also by the use of
public/private key cryptography.
In describing ssh here, the term client means a workstation or PC that you are already logged in to, e.g., your own personal workstation or a group workstation that provides XDM session management for several X terminals. The term server means a secondary remote workstation that you wish to log in to to do some work; a login session server.
Put simply, the client is where you type "rlogin server" or "rcp file server:newfile" and the server is where you get a new login session and shell prompt or are copying files, respectively.
As a user, you generate an "identity" on the client system by running the ssh-keygen program. This program creates a subdirectory $HOME/.ssh and inserts in it two files named identity and identity.pub which contain your private and public keys for your account on the client system. This latter file can then be appended to a file $HOME/.ssh/authorized_keys that should reside on any/all servers where you will make ssh connections.
As a system administrator, you generate a public and private key pair for the system itself. By use of this information contained within the system itself, the possibility of someone spoofing the system's identity by faking IP addresses or munging up DNS records that associate IP addresses and domain names is removed. You would have to break into the system and steal its private key in order to sucessfully pretend to be that system. This is a big improvement in security.
The biggest task if you manage a large number of systems that are meant to be used together is collecting and distributing the keys that identify all the hosts which run ssh. Tools exist for handling this task: ssh includes the program make-ssh-known-hosts.pl (which requires POSIX.pm be installed in your Perl library directory) and another script (http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list) is available on the Internet.
See also: Kimmo Suominen's Getting started with SSH.
How do I use ssh?
First, you need to get and install ssh
on your client workstation, plus it must be installed on the remote
system you wish to connect to. You can do this for your own account,
or your system administrator can install it for the entire system.
Once installed, there are several ways you can use ssh, each with varying steps you must go through first.
The most basic use of ssh is transparent when compared with the standard Berkeley "r" utilities. In fact, a system administrator can install ssh on both client and remote server workstations and users who connect using rlogin server will see no difference whatsoever, nor will they need to know anything new. This kind of use gets you the most basic protection of encrypted sessions from systems with ssh installed, usually with a fall back capability to the old (and less secure) Berkeley methods if the other system does not support ssh.
If you wish to make security tighter, you can stop using .rhosts and /etc/hosts.equiv files (or disable the Berkeley utilities altogether) and only allow passwordless connections with ssh keys.
Each system has its own public/private key pair that identifies it to other systems. A client system's public key can be placed in a server system's /etc/ssh_known_hosts file to allow the server to authenticate the client by a key exchange dialog.
If the client host's public key (from the /etc/ssh_host_key.pub file) is found in the in the server's /etc/ssh_known_hosts file, and you place the host name in your own .rhosts or .shosts file, you get the same passwordless connection behavior as the standard Berkeley "r" utilities. If the client's key is not found, ssh will prompt you for the password on the server and will transmit this password -- in encrypted form, rather than plain text -- to the server for authenticating your login. This method involves the system administrator, who must place the client's public keys in the server's /etc/ssh_known_hosts file. There is another way to use ssh that doesn't require the administrator's intervention.
Each user account also has a public and private key that identifies that user account. You get this key when you run the ssh-keygen program. It creates a directory called $HOME/.ssh and puts the keys in there. You can now take your public key, found in the $HOME/.ssh/identity.pub file and place it on the server in your $HOME/.ssh/authorized_keys file. Once you have done this, even though the server doesn't know the key of the client workstation, it does now know your key and will allow the login to your account without a password.
To use the X Window System protocol tunneling (if enabled), you only need to log in successfully and ssh will create a DISPLAY environment variable for you that points to a proxy X server on the server system, which passes X protocol traffic to the real X server on the client system. You can start running X client programs as soon as you get a shell prompt.
Where can you get ssh or more information about it?
There are many more advanced configuration options that deal with
authentication, fall back mechanisms to the Berkeley "r" utilities,
etc., but they go beyond the scope of this introduction.
As of July 2000, there are now two other free implementations (OpenSSH and LSH) of the SSH protocol besides the original version of SSH from HUT. Source code is available from:
For more on SSH, see the following.