SSH is one of the premier Security tools in use today. SSH is most commonly used to gain a remote shell, but it can be used for file transfers, to display remote X applications on a local machine, and even to securely connect to services that lack encryption. Unfortunately, many who use it from day to day don't have a good understanding of how it actually works. Many people know that SSH1 is deprecated, and that SSH2 has taken its place, but how many know how authentication actually works for both? I didn't, and that bothered me, so I set out to do some research. . . .
SSH is one of the premier Security tools in use today. SSH is most commonly used to gain a remote shell, but it can be used for file transfers, to display remote X applications on a local machine, and even to securely connect to services that lack encryption. Unfortunately, many who use it from day to day don't have a good understanding of how it actually works. Many people know that SSH1 is deprecated, and that SSH2 has taken its place, but how many know how authentication actually works for both? I didn't, and that bothered me, so I set out to do some research.

This is by no means a "serious" paper - let's be clear about that. A true "paper" (in the Infosec world) brings forward a ground-breaking idea and explains it in technical detail. This paper, on the other hand, is designed to convey, using efficient language, information that is already understood by a relatively small number of people (in this case cryptographers). In short, I am attempting to pass on *understanding* rather than information. My goal is to provide an overview (hence the name) of how SSH1 authentication differs from SSH2 authentication, followed by a brief foray into the use of RSA/DSA key pairs for user authentication. Ok, with that said, let's begin.

First off, SSH has two main protocol versions - SSH1 and SSH2. SSH2 is the newer version and it is highly recommended that anyone running an SSH server only allow clients to use SSH2. This is accomplished by editing your sshd_config file and removing the 1 from the "Protocols" line toward the top of the file. This will prohibit the daemon from "falling back" to SSH1 in the event that a client doesn't speak SSH2.

The link for this article located at neworder.box.sk is no longer available.