I was recently asked how I would describe SSH to the person's mother. Assuming that English is her native tongue, I gave the first explanation that came to mind. This explanation involved the use of puzzle pieces and colorful napkins. I originally didn't plan to to rehash that here. Instead, I thought I would refresh myself on the protocol (SSH 2.0) and write it up...so it's maybe fresher in my mind as it has admittedly been quite a while since I have gotten into the nuts and bolts of SSH. I think I will do a little of both. :-) To keep it simple (I hope) I will first discuss SSH from the more nerdy side of life and will break the discussion into
The Players:
CLIENT
SERVER
Switch 1 (just be cognizant that my discussion here involves communication between the CLIENT and SERVER using Switch 1)
Initial Session Setup
First, the same old three-way handshake.
CLIENT sends the
SYN packet to SERVER
SERVER sends the
SYN,ACK packet to CLIENT
CLIENT sends the final
ACK packet of the handshake to SERVER
 |
| Figure 1: TCP Handshake |
[RFC4523:4.2]
Protocol Version Exchange
Once the initial
TCP-Handshake is accomplished, both Hosts announce to each other what
protocol version they are running. This is known as the identification
string and has the following format:
SSH-protoversion-softwareversion SP comments CR LF
 |
| Figure 2: SSH Protocol Version Exchange |
There are a few variations of these strings and these [variations] are based upon the version of the client and the server. The identification string is "usually" sent first by the server (SERVER in this example). This string sent by the server should be the only bit of information sent by the server until the client (CLIENT) verifies the version of the protocol that the client is using. A full discussion of this can be found in the RFC itself, but here's a quick breakdown:
SSH = should be obvious...but if not...try
Basic Protocol Help first. :-)
-protoversion = If this doesn't say 2.0 from the server, I'd avoid connecting...just sayin'
-softwareversion = No real concrete value. Basically, if it conforms to the applicable RFC's, it's fair game.
SP = literally, a SPACE character (ASCII 32)...NOT A NULL!!! This is ONLY needed if there are comments
comments - the identification string has a max length of 255. This section can be arbitrary but it is usually used by the server (again, SERVER in this case) to initiate the Diffie-Hellman key exchange.
- a few other quick notes:
-protoversion = must contain only printable US-ASCII characters with the exception of the minus sign and spaces
-softwareversion = "used to trigger compatibility extensions and to indicate the capabilities of an implementation" (RFC4253)
-comments = this should be used to provide helpful information to the user(s).
- There can be multiple lines sent by the client or server as long as:
- ONLY the first line starts with "SSH"
- each line MUST end with a Carriage Return(CR, ASCII 13) and Line Feed(LF ASCII 10)
[RFC4253:8]
Diffie-Hellman Key Exchange
SSH makes use of Diffie-Hellman to complete the key exchange between the CLIENT and SERVER. I am not going to get into Diffie-Hellman here other than to quickly cover its role in the SSH process. Suffice to say that it has been around for a few days, since 1971 I believe, and is a very creative way to perform the key exchange.
 |
| Figure 3: DH Key Exchange |
Encrypted Traffic
Once the protocol is agreed upon and the key exchange is completed, the traffic is then encrypted. The key used for encryption can be changed during the conversation.
 |
| Figure 4: Encrypted SSH Traffic and Session Teardown |
Misc Notes
It is germane to note that the RFC defines additional, individual, items that can be used:
- The servery key_algorithm, the encryption_algorithm, and the mac_algorithm are required by the RFC to be a match between the Servers options and the
FIRST matching option from the Client's list.
- MAC: Message Authentication Code, if its usage is agreed upon then each binary packet except the first will contain the MAC as the last field in the payload.
- compression: compression can be used when agreed upon by both the server and client. The RFC provides an interesting discussion in packet size and compression and how this may/may not affect network traffic.
- Key Change: a key change may be initiated by either side by sending a SSH_MSG_KEXINIT. The RFC does stipulate that the roles MUST NOT be changed, regardless of who initiates the key change process.
Now, back to telling your mother about SSH.
The Players:
Yourself (Client)
Your Mom(Server)
Puzzle Pieces
Different Color Napkins
Initial Session Setup
You know that you need to give your mother some puzzle pieces. However, the wind is blowing fiercely, the rain is pellting you both, and you must pass the pieces to your mother over a large crater between the both of you. So...
You call out to your mother: "Yo!"
Your Mom hollers back: "Yo, I can hear you!"
To which you holler: "I can hear you!"
Protocol Version Exchange
You mother lets you know that she can work with pieces from the 5000pc puzzle depicting the 1984 Detroit Tigers.
You have pieces for this puzzle and therefore let her know that this will work well for you.
Diffie-Hellman Key Exchange
Your mother now lets you know that she can use the puzzle pieces from
your left and right jeans pockets and from your left coat pockets.
Your mother also lets you know that she can accept the pieces wrapped in Blue, Maize, or Orange.
You
let your mother know that you do, in fact, have puzzle pieces in your
left jeans pocket and in your left and right coat pockets.
You also let her know that you have the ability to use Maize or Orange colored Napkins.
Because
you first mentioned the left jeans pocket and your mother can use this,
these are the pieces you will be passing to your mother. Likewise, because you first listed the Maize colored napkins, the pieces will be wrapped with said napkins, as will any response from your mother.
Encrypted Traffic
Completing this puzzle is important to you. As such, you've contacted your mother, agreed upon which type of pieces are needed, and how to protect said pieces from the wind and rain. After you've agreed upon the pieces and the protection, there is no need for you to yell across the hole between the two of you.
So, I hope that this post will make sense to me in a year, and to anyone else who may read it. I left out some of the more technical things on purpose, especially the under-workings of the Diffie-Hellman protocol.
