Introduction to SSH
From CLUG Wiki
This article tries to explain the concepts behind and usefulness of SSH in plain prose. It has a bias toward the Linux operating system, since we (the authors of this document) use SSH on Linux. This article does not go into technical or installation detail, the corresponding FAQ or README are likely to cover that.
Contents |
UCT Preamble
We think it is a good idea to use SSH on the UCT network. While we have not yet had reports of people sniffing passwords off the network, there is no guarantee that this will not happened (or has not happened), since there are a number of packet sniffers available for Linux and other systems, which would allow the user to collect all packets on the local segment and scan them for such interesting strings as ogin*ssword
Introduction
SSH is a program suite which should allow you use remote systems in a more secure manner. It does not guarantee absolute protection. Just because you use SSH does not mean your system can not be compromised. Always practice safe hex.
There are however significant gains to be had from using SSH - it allows you to work over an untrusted network with protection from at least casual snooping. It does not protect you at all from attacks originating on the local machine (the computer you are sitting at) or the remote machine (the one which you are trying to log on to). As a matter of fact, anyone with root privileges on either system can pretty much observe anything you do. If you do not believe that, go into the /proc directory, select the directory with a number which matches the PID of a shell, for example, log in as root, and examine its environment, command line, read from the file streams or even invoke a copy of the running process.
The above is not as bad as it sounds - you generally trust the remote machine (otherwise you would not be using it - right ?) as well as the local machine (especially if it is the one sitting at home on your desk). The element which tends to be the least trustworthy is the network. The local machine can be several hops away from the remote one, and each segment could host an eavesdropper... and SSH is designed to minimize the risk of such an eavesdropper cquiring your password, credit card number or letter.
Mechanics
The life of a message sent across an unfriendly network is fraught with many hazards:
The message could be copied by a listener (we will call that sniffing), it could be accepted by a hostile host (which only pretends to be your trusted remote host - lets invoke our poetic license and call that spoofing) or, even more twisted, the message could be grabbed by a hostile intermediate, modified and then... sent onto the real host (we call that man-in-the-middle attack, although that name is certainly going to be revised to something less sexist).
Clearly a plain text remote login is vulnerable to any form of this attack, while a login using SSH is reasonably well protected from the first and vulnerable to the second and third only on the first log-in thus requiring the person-in-the-middle to be highly motivated and always active.
Protection from a sniffing attack is provided by an encryption method call public key encryption. Public key encryption is an extraordinary encryption method which does allow you to publicly advertise the key which you want someone to use when sending you a message. This is a marvelous invention... parties which never met in a trusted environment can now talk to each other. Plain encryption never allows that: You want to send someone a message - you encrypt the message with a neat password - and then you need to send the password - and everyone can grab your password. So plain encryption is somewhat limited. Public key encryption uses two asymmetrical keys, one to encrypt, and one to decrypt (and it is highly time consuming to derive one from the other - so time consuming that in most cases it would keep generations of eavesdroppers owning powerful computers quite busy). At any rate, you advertise the key used to encrypt, but keep the key to decrypt to yourself. Now anyone who wants to send you a message can. SSH generates such a key pair for the remote host, the local machine acquires the key, encrypts a message, sends it to the remote host which will have to prove its identity by decrypting that message and send it back (actually the story is somewhat more complicated, since the local machine also has its own key pair, and the session also has its own key, but we will ignore that). Anyways, the two hosts have a way of talking to each other (usually they then use that safe environment to agree on keys for a plain encryption method and use the plain fast method to continue their communications).
Protection from spoofing (spoofing according to our definitions) is a bit more difficult. Fortunately spoofing is also more difficult than plain listening (the hostile host has to convince the network that it is actually the host you want to connect to), but once a spoofing host has been set up, the host can pretend to be the legal host, and even include nifty public keys of its own. The host then only needs to get you to type in your password. Fortunately this only works on the first time, since SSH on the local host will save the key of remote hosts and compare them on each new session - if it detects an inconsistency it will alert you to the fact.
A person-in-the-middle attack is equally tricky to accomplish. The person-in-the-middle will also have to be around every time you connect to the remote machine, otherwise the saved key will not match the one provided by the host - and you will be told so.
The rhost replacement
On conventional UNIX systems there exists a way of connecting to a remote host without having to provide a password. You simply tell the remote host during an earlier session that a user X at machine Y is permitted to log into that machine without ever needing to identify him/herself again. The files controlling this are /etc/hosts.equiv and ~/.rhosts. This method is quite unsafe. A nefarious individual only needs to pretend (fool the remote host into believing that x@y is talking to it) to be you.
SSH offers a slight improvement over this method - since each client (your local host) also owns a private and a public key, you can, at an earlier time, copy the public key of the local machine to the remote one. So any malicious client pretending to be you will have to back up the claim by decrypting a message encrypted with your public key - and that is only possible with the private key stored securely on the local host. This approach is quite safe... it does not expose you to attacks from the network. But note that if the local machine is compromised the remote machine will be too. If the local machine in question is sitting on your desk at home, then that should be ok. But if the machine, say, mounts your home directory from somewhere over the network via NFS, then anyone on that part of the network will be able to read the private key, and you will have gained little.
The xhost replacement
So far we have concentrated on a plain terminal session to a remote host. Occasionally you might want to start an X application which displays to your local display. Normally you would have to disable the xauth authentication method (by typing something like: xhost remotehost). There is a risk associated with that... anybody else on the remote host will now also be able to connect. So SSH (transparently) sets up a proxy on the remote host when you log in (to which only you on the remote host can connect) which forwards all connections to the local screen via the encrypted channel. Usually you do not need to bother setting up anything - just do not override the remote DISPLAY variable, SSH sets it up for you.
