Tuesday, 1 July 2014

The Secure Shell (ssh)

What is ssh?

Ssh is set of programs which employ public/private key technology for authenticating and encrypting sessions between user accounts on distributed hosts on the Internet. It can be compiled and used by a normal user without having to ask permission or assistance from the system administrator, or the system administrator can install it as a plug-in replacement for the Berkeley "r" utilities without the users needing to know it is there at all (or do anything to learn how to use it).
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.