Cryptography of SSH

This is an overview of the SSH2 protocol, with a focus on how it uses cryptography to accomplish many of its goals: authentication, integrity, and confidentiality. The information is derived from client-side debug output; a network packet capture; protocol decoding by Ethereal; RFC drafts for SSH-ARCH, SSH-TRANS, SSH-AUTH, SSH-CONN; O'Reilly's Secure Shell Definitive Guide, VPNs Illustrated, and Practical Cryptography. The expected product of the guide is an ability to detect insecure client and/or server settings and recognize anomalies during session establishment. The sections are organized by order of which they occur during an SSH2 login.

Section 1

In this example, host .14 (the client) establishes a TCP connection to port 22 of host .11 (the server), the two sides announce SSH versions, and the key exchange initialization takes place. For brevity, the 3-way handshake is the only sub-section in which either side's acknowledgment (ACK) packets affect the packet count. Following section 1, the two peers will have derived the following information:

TCP 3-way handshake (packets 1, 2 3)

If you're reading this, then likely you already know the significance of the 3-way handshake. It is provided here to be complete. Using the -v option when calling the SSH client on .14, these three packets produce the output:

The network packet captures in this document are recorded with Ethereal. Here are the first three:

Version string announcement (packets 4, 5)

There are two main, incompatible, versions of the SSH protocol: SSH1 (1.5) and SSH2. Most recent implementations still support both protocols, though support for the older, less secure SSH1 version should not be used. One major reason is because SSH1 only applies a CRC32 (cyclancy redundancy check) to the message for integrity, rather than a MAC (message authentication code). CRCs are not collision-resistant functions and are normally just used to detect accidental errors in transmissions (IP, TCP, and UDP, for example, use a checksum in their headers). MACs, on the other hand, are strengthened by using a cryotographic hash such as MD5 or SHA1.

In this sub-section, two packets are exchanged. The server sends it's protocol version first and the client replies with it's own version. A special code "1.99" specifies that the sender supports both SSH1 and SSH2. In our example, the client and server both suport SSH2 only.

If the protocol versions are compatible, the connection progresses to the next step. If they are not, then either peer can force a termination. View the packet capture for a closer look at the traffic that produces the above output.

SSH2_MSG_KEXINIT exchange (packets 6, 7)

The primary objective of this round-trip exchange is to negotiate the algorithms for key exchange, bulk data encryption, message integrity, and compression. The peers will also let each other know the accepted host key types. In this stage they present their supported and preferred methods for the aforementioned functions in comma seperated list form. Preferred values are distinguished by placing them first in the list.

Two of the common key exchange methods are represented as diffie-hellman-group-exchange-sha1 and diffie-hellman-group1-sha1. The later method is less secure, because it uses a fixed group with which to make it's calculations. If diffie-hellman-group-exchange-sha1 (otherwise known as DHGEX) is selected, the group to use is negotiated based on the client's minimum, maximum, and preferred size prime modulus; from which the server chooses an appropriate value (see the SSH2_MSG_KEXDH_GEX_GROUP message in packet 9).

For bulk data encryption, SSH uses a symetric algorithm to scramble the message. Asymetric algorithms are simply not efficient when applied to bulk data, because they are too slow. The key used for this function is then encrypted with the peer's public host key to ensure that only a host with the corresponding private key can reproduce it. Without knowing the symetric algorithm key, the original message itself cannot be decrypted. So, upon receipt of the packet, a peer would use it's private key to decrypt the symetric algorithm key; and then use that resulting value to derive the plaintext message.

For data integrity, the two peers agree to use a common MAC algorithm. Encryption alone does not prove to the recipient that the remote peer truly generated and sent a message, and further more it does not prevent against alteration of the data. In fact, encryption does not even attempt to do this - it assumes the data will be available to anyone, and just makes it's best attempt to prevent it from being readable. MACs fill in this void by computing a hash of the unencrypted message body, a shared secret, and a session sequence number; which is then sent to the recipient. The shared secret is a product of the Diffie Hellman key exchange (section 2) and is computed individually by each peer, without needing to transmit over the network.

Without the MAC, an eavesdropper (man in the middle) could capture parts of the encrypted conversation (though not necessarily be able to read it) and conduct a replay attack, where s/he duplicates and resends that part of the converstation at a later point in time. The packet would still contain a payload signed with the recipient's public key, and the message would be encrypted with the expected symetric algorithm key; thus it would seem quite reasonable to the recipient. The session sequence number here is critical. It begins at 0 and increments by 1 for each message. Since this is a factor in the computation of the MAC value, only the sender can produce a legitimate code; and the recipient will only accept each code once - in the proper order. The MAC is not included in packets until after the SSH2_MSG_NEWKEYS is sent (packet 12).

SSH optionally will compress transmissions for more efficient delivery. Zlib is the only supported scheme according to the RFCs, but they are only drafts so this is subject to change. In the case that compression is negotiated, it is applied only to the message body and occurs before any MAC or encryption routines. Notice above that the client->server and server->client algorithms match; they both have chosen the same bulk data, integrity, and compression methods. This may be the case here, but it is not required. Data flow in both directions is independent of each other. The server could encrypt it's messages with AES128 and compress it with zlib, and the client could encrypt it's replies with 3DES with no compression.

Additionally, in this sub-section, the client and server both generate a sequence of 16 random bytes known as a cookie. This value is used in the key generation process, to ensure that neither side can completely determine the keys on it's own.

/* Packet 6 */
Internet Protocol, Src: 192.168.1.11 (192.168.1.11), Dst: 192.168.1.14 (192.168.1.14)
Transmission Control Protocol, Src Port: 22 (22), Dst Port: 55821 (55821), Seq: 21, Ack: 21, Len: 640
SSH Protocol
    SSH Version 2
        Packet Length: 636
        Padding Length: 11
        Key Exchange
            Msg code: Key Exchange Init (20)
            Algorithms
                Cookie: E943B8EAD89BC6BD6861A54CFD333DB0
                kex_algorithms length: 89
                kex_algorithms string: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,
                  diffie-hellman-group1-sha1
                server_host_key_algorithms length: 15
                server_host_key_algorithms string: ssh-rsa,ssh-dss
                encryption_algorithms_client_to_server length: 135
                encryption_algorithms_client_to_server string: aes128-cbc,3des-cbc,blowfish-cbc,
                  cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,
                  aes192-ctr,aes256-ctr
                encryption_algorithms_server_to_client length: 135
                encryption_algorithms_server_to_client string: aes128-cbc,3des-cbc,blowfish-cbc,
                  cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,
                  aes192-ctr,aes256-ctr
                mac_algorithms_client_to_server length: 85
                mac_algorithms_client_to_server string: hmac-md5,hmac-sha1,hmac-ripemd160,
                  hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
                mac_algorithms_server_to_client length: 85
                mac_algorithms_server_to_client string: hmac-md5,hmac-sha1,hmac-ripemd160,
                  hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
                compression_algorithms_client_to_server length: 9
                compression_algorithms_client_to_server string: none,zlib
                compression_algorithms_server_to_client length: 9
                compression_algorithms_server_to_client string: none,zlib
                languages_client_to_server length: 0
                languages_server_to_client length: 0
            Payload: 0000000000
            Padding String: 

0000  00 0c 29 6d 5c 01 00 50 2c 05 6b a9 08 00 45 00   ..)m\..P,.k...E.
0010  02 b4 55 24 40 00 40 06 5f b6 c0 a8 01 0b c0 a8   ..U$@.@._.......
0020  01 0e 00 16 da 0d 64 6e 28 d5 16 bc c7 48 80 18   ......dn(....H..
0030  05 a8 79 e0 00 00 01 01 08 0a 0b 79 7d e5 04 99   ..y........y}...
0040  fe e0 00 00 02 7c 0b 14 e9 43 b8 ea d8 9b c6 bd   .....|...C......
0050  68 61 a5 4c fd 33 3d b0 00 00 00 59 64 69 66 66   ha.L.3=....Ydiff
0060  69 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 6f 75 70   ie-hellman-group
0070  2d 65 78 63 68 61 6e 67 65 2d 73 68 61 31 2c 64   -exchange-sha1,d
0080  69 66 66 69 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72   iffie-hellman-gr
0090  6f 75 70 31 34 2d 73 68 61 31 2c 64 69 66 66 69   oup14-sha1,diffi
00a0  65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 6f 75 70 31   e-hellman-group1
00b0  2d 73 68 61 31 00 00 00 0f 73 73 68 2d 72 73 61   -sha1....ssh-rsa
00c0  2c 73 73 68 2d 64 73 73 00 00 00 87 61 65 73 31   ,ssh-dss....aes1
00d0  32 38 2d 63 62 63 2c 33 64 65 73 2d 63 62 63 2c   28-cbc,3des-cbc,
00e0  62 6c 6f 77 66 69 73 68 2d 63 62 63 2c 63 61 73   blowfish-cbc,cas
00f0  74 31 32 38 2d 63 62 63 2c 61 72 63 66 6f 75 72   t128-cbc,arcfour
0100  2c 61 65 73 31 39 32 2d 63 62 63 2c 61 65 73 32   ,aes192-cbc,aes2
0110  35 36 2d 63 62 63 2c 72 69 6a 6e 64 61 65 6c 2d   56-cbc,rijndael-
0120  63 62 63 40 6c 79 73 61 74 6f 72 2e 6c 69 75 2e   cbc@lysator.liu.
0130  73 65 2c 61 65 73 31 32 38 2d 63 74 72 2c 61 65   se,aes128-ctr,ae
0140  73 31 39 32 2d 63 74 72 2c 61 65 73 32 35 36 2d   s192-ctr,aes256-
0150  63 74 72 00 00 00 87 61 65 73 31 32 38 2d 63 62   ctr....aes128-cb
0160  63 2c 33 64 65 73 2d 63 62 63 2c 62 6c 6f 77 66   c,3des-cbc,blowf
0170  69 73 68 2d 63 62 63 2c 63 61 73 74 31 32 38 2d   ish-cbc,cast128-
0180  63 62 63 2c 61 72 63 66 6f 75 72 2c 61 65 73 31   cbc,arcfour,aes1
0190  39 32 2d 63 62 63 2c 61 65 73 32 35 36 2d 63 62   92-cbc,aes256-cb
01a0  63 2c 72 69 6a 6e 64 61 65 6c 2d 63 62 63 40 6c   c,rijndael-cbc@l
01b0  79 73 61 74 6f 72 2e 6c 69 75 2e 73 65 2c 61 65   ysator.liu.se,ae
01c0  73 31 32 38 2d 63 74 72 2c 61 65 73 31 39 32 2d   s128-ctr,aes192-
01d0  63 74 72 2c 61 65 73 32 35 36 2d 63 74 72 00 00   ctr,aes256-ctr..
01e0  00 55 68 6d 61 63 2d 6d 64 35 2c 68 6d 61 63 2d   .Uhmac-md5,hmac-
01f0  73 68 61 31 2c 68 6d 61 63 2d 72 69 70 65 6d 64   sha1,hmac-ripemd
0200  31 36 30 2c 68 6d 61 63 2d 72 69 70 65 6d 64 31   160,hmac-ripemd1
0210  36 30 40 6f 70 65 6e 73 73 68 2e 63 6f 6d 2c 68   60@openssh.com,h
0220  6d 61 63 2d 73 68 61 31 2d 39 36 2c 68 6d 61 63   mac-sha1-96,hmac
0230  2d 6d 64 35 2d 39 36 00 00 00 55 68 6d 61 63 2d   -md5-96...Uhmac-
0240  6d 64 35 2c 68 6d 61 63 2d 73 68 61 31 2c 68 6d   md5,hmac-sha1,hm
0250  61 63 2d 72 69 70 65 6d 64 31 36 30 2c 68 6d 61   ac-ripemd160,hma
0260  63 2d 72 69 70 65 6d 64 31 36 30 40 6f 70 65 6e   c-ripemd160@open
0270  73 73 68 2e 63 6f 6d 2c 68 6d 61 63 2d 73 68 61   ssh.com,hmac-sha
0280  31 2d 39 36 2c 68 6d 61 63 2d 6d 64 35 2d 39 36   1-96,hmac-md5-96
0290  00 00 00 09 6e 6f 6e 65 2c 7a 6c 69 62 00 00 00   ....none,zlib...
02a0  09 6e 6f 6e 65 2c 7a 6c 69 62 00 00 00 00 00 00   .none,zlib......
02b0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
02c0  00 00                                             ..

/* Packet 7 */
Internet Protocol, Src: 192.168.1.14 (192.168.1.14), Dst: 192.168.1.11 (192.168.1.11)
Transmission Control Protocol, Src Port: 55821 (55821), Dst Port: 22 (22), Seq: 21, Ack: 661, Len: 712
SSH Protocol
    SSH Version 2
        Packet Length: 708
        Padding Length: 5
        Key Exchange
            Msg code: Key Exchange Init (20)
            Algorithms
                Cookie: 4C07661B0E42B52E6081306F2714EDC3
                kex_algorithms length: 89
                kex_algorithms string: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,
                  diffie-hellman-group1-sha1
                server_host_key_algorithms length: 15
                server_host_key_algorithms string: ssh-rsa,ssh-dss
                encryption_algorithms_client_to_server length: 157
                encryption_algorithms_client_to_server string: aes128-cbc,3des-cbc,blowfish-cbc,
                  cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,
                  rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
                encryption_algorithms_server_to_client length: 157
                encryption_algorithms_server_to_client string: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,
                  arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,
                  aes192-ctr,aes256-ctr
                mac_algorithms_client_to_server length: 85
                mac_algorithms_client_to_server string: hmac-md5,hmac-sha1,hmac-ripemd160,
                  hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
                mac_algorithms_server_to_client length: 85
                mac_algorithms_server_to_client string: hmac-md5,hmac-sha1,hmac-ripemd160,
                  hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
                compression_algorithms_client_to_server length: 26
                compression_algorithms_client_to_server string: none,zlib@openssh.com,zlib
                compression_algorithms_server_to_client length: 26
                compression_algorithms_server_to_client string: none,zlib@openssh.com,zlib
                languages_client_to_server length: 0
                languages_server_to_client length: 0
            Payload: 0000000000
            Padding String: 

0000  00 50 2c 05 6b a9 00 0c 29 6d 5c 01 08 00 45 00   .P,.k...)m\...E.
0010  02 fc 39 d7 40 00 40 06 7a bb c0 a8 01 0e c0 a8   ..9.@.@.z.......
0020  01 0b da 0d 00 16 16 bc c7 48 64 6e 2b 55 80 18   .........Hdn+U..
0030  06 f4 78 4e 00 00 01 01 08 0a 04 99 fe e0 0b 79   ..xN...........y
0040  7d e5 00 00 02 c4 05 14 4c 07 66 1b 0e 42 b5 2e   }.......L.f..B..
0050  60 81 30 6f 27 14 ed c3 00 00 00 59 64 69 66 66   `.0o'......Ydiff
0060  69 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 6f 75 70   ie-hellman-group
0070  2d 65 78 63 68 61 6e 67 65 2d 73 68 61 31 2c 64   -exchange-sha1,d
0080  69 66 66 69 65 2d 68 65 6c 6c 6d 61 6e 2d 67 72   iffie-hellman-gr
0090  6f 75 70 31 34 2d 73 68 61 31 2c 64 69 66 66 69   oup14-sha1,diffi
00a0  65 2d 68 65 6c 6c 6d 61 6e 2d 67 72 6f 75 70 31   e-hellman-group1
00b0  2d 73 68 61 31 00 00 00 0f 73 73 68 2d 72 73 61   -sha1....ssh-rsa
00c0  2c 73 73 68 2d 64 73 73 00 00 00 9d 61 65 73 31   ,ssh-dss....aes1
00d0  32 38 2d 63 62 63 2c 33 64 65 73 2d 63 62 63 2c   28-cbc,3des-cbc,
00e0  62 6c 6f 77 66 69 73 68 2d 63 62 63 2c 63 61 73   blowfish-cbc,cas
00f0  74 31 32 38 2d 63 62 63 2c 61 72 63 66 6f 75 72   t128-cbc,arcfour
0100  31 32 38 2c 61 72 63 66 6f 75 72 32 35 36 2c 61   128,arcfour256,a
0110  72 63 66 6f 75 72 2c 61 65 73 31 39 32 2d 63 62   rcfour,aes192-cb
0120  63 2c 61 65 73 32 35 36 2d 63 62 63 2c 72 69 6a   c,aes256-cbc,rij
0130  6e 64 61 65 6c 2d 63 62 63 40 6c 79 73 61 74 6f   ndael-cbc@lysato
0140  72 2e 6c 69 75 2e 73 65 2c 61 65 73 31 32 38 2d   r.liu.se,aes128-
0150  63 74 72 2c 61 65 73 31 39 32 2d 63 74 72 2c 61   ctr,aes192-ctr,a
0160  65 73 32 35 36 2d 63 74 72 00 00 00 9d 61 65 73   es256-ctr....aes
0170  31 32 38 2d 63 62 63 2c 33 64 65 73 2d 63 62 63   128-cbc,3des-cbc
0180  2c 62 6c 6f 77 66 69 73 68 2d 63 62 63 2c 63 61   ,blowfish-cbc,ca
0190  73 74 31 32 38 2d 63 62 63 2c 61 72 63 66 6f 75   st128-cbc,arcfou
01a0  72 31 32 38 2c 61 72 63 66 6f 75 72 32 35 36 2c   r128,arcfour256,
01b0  61 72 63 66 6f 75 72 2c 61 65 73 31 39 32 2d 63   arcfour,aes192-c
01c0  62 63 2c 61 65 73 32 35 36 2d 63 62 63 2c 72 69   bc,aes256-cbc,ri
01d0  6a 6e 64 61 65 6c 2d 63 62 63 40 6c 79 73 61 74   jndael-cbc@lysat
01e0  6f 72 2e 6c 69 75 2e 73 65 2c 61 65 73 31 32 38   or.liu.se,aes128
01f0  2d 63 74 72 2c 61 65 73 31 39 32 2d 63 74 72 2c   -ctr,aes192-ctr,
0200  61 65 73 32 35 36 2d 63 74 72 00 00 00 55 68 6d   aes256-ctr...Uhm
0210  61 63 2d 6d 64 35 2c 68 6d 61 63 2d 73 68 61 31   ac-md5,hmac-sha1
0220  2c 68 6d 61 63 2d 72 69 70 65 6d 64 31 36 30 2c   ,hmac-ripemd160,
0230  68 6d 61 63 2d 72 69 70 65 6d 64 31 36 30 40 6f   hmac-ripemd160@o
0240  70 65 6e 73 73 68 2e 63 6f 6d 2c 68 6d 61 63 2d   penssh.com,hmac-
0250  73 68 61 31 2d 39 36 2c 68 6d 61 63 2d 6d 64 35   sha1-96,hmac-md5
0260  2d 39 36 00 00 00 55 68 6d 61 63 2d 6d 64 35 2c   -96...Uhmac-md5,
0270  68 6d 61 63 2d 73 68 61 31 2c 68 6d 61 63 2d 72   hmac-sha1,hmac-r
0280  69 70 65 6d 64 31 36 30 2c 68 6d 61 63 2d 72 69   ipemd160,hmac-ri
0290  70 65 6d 64 31 36 30 40 6f 70 65 6e 73 73 68 2e   pemd160@openssh.
02a0  63 6f 6d 2c 68 6d 61 63 2d 73 68 61 31 2d 39 36   com,hmac-sha1-96
02b0  2c 68 6d 61 63 2d 6d 64 35 2d 39 36 00 00 00 1a   ,hmac-md5-96....
02c0  6e 6f 6e 65 2c 7a 6c 69 62 40 6f 70 65 6e 73 73   none,zlib@openss
02d0  68 2e 63 6f 6d 2c 7a 6c 69 62 00 00 00 1a 6e 6f   h.com,zlib....no
02e0  6e 65 2c 7a 6c 69 62 40 6f 70 65 6e 73 73 68 2e   ne,zlib@openssh.
02f0  63 6f 6d 2c 7a 6c 69 62 00 00 00 00 00 00 00 00   com,zlib........
0300  00 00 00 00 00 00 00 00 00 00                     ..........

Section 2

This section involves key exchange, using the selected Diffie Hellman protocol. By using this method properly, the two peers can derive the same secret key through plain text communications, without the possibility of eavesdroppers being able to calculate the same value. DH is not a total package solution, because it does not prevent man-in-the-middle data alteration. This attack will be described shortly. Following section 2, the peers will have derived the following information:

SSH2_MSG_KEXDH_GEX_REQUEST (packet 8)

As mentioned earlier, if diffie-hellman-group-exchange-sha1 is selected as the key exchange method, the client notifies the server of it's minimum, preferred, and maximum prime size for the group. As the debug output shows, the numers are 1024, 1024, and 8192, respectively. The 32-bit unsigned integers have been highlighted below.

SSH2_MSG_KEXDH_GEX_GROUP (packet 9)

This is the server's response to the SSH2_MSG_KEXDH_GEX_REQUEST. From the available options, the server selects an appropriate size for the group's prime and informs the client. This packet also contains two multiprecision integers containing the prime to be used (p) and the corresponding generator (g). After receiving this message, both peers know the DH group to use. There are only two remaining packets in the key exchange (packets 10 and 11) before enough parameters are negotiated to start encrypting data..

SSH2_MSG_KEXDH_GEX_INIT (packet 10)

In this sub-section, the client computes a value based on p and g and sends it to the server. In particular, the client generates a random number x, such that 1 < x < (p-1)/2 and then calculates e = g^x mod p. In the below packet capture, you can see "e" being sent to the server, sandwiched between one 0x20 and six 0x00 bytes. The 0x20 (decimal 32) specifies the message type, which is Diffie-Hellman GEX Init in this case. This is important to note, because a message type of 0x20 with an inconsistent payload might be indication of some type of attack or reconnassance.

SSH2_MSG_KEXDH_GEX_REPLY (packet 11)

Upon receipt of the client's SSH2_MSG_KEXDH_GEX_INIT message, the server generates it's own random number y, calculates f = g^y mod p, and sends "f" to the client. It also calculates k = e^y mod p, which is the value of the shared secret. The client does the same, using formula k = f^x mod p. If everything goes right, the client and server should compute identical values for k. This is very important, because k is one of the elements used to create the exchange hash signature, which is the primary factor in server authentication.

The exchange hash is created by contatenating several pieces of the puzzle, one of which is the value of k. It is also built with e, f, and data such as the client and server's version strings. Once collected, the combined data is run through the negotiated hashing algorithm, which is then signed with the server's private key. Included in this same packet is the server's public key.

The first time .14 connects to .11, this public key is recorded in the client's known_hosts database (~/.ssh/known_hosts), which is then used in comparison against the key sent by the server on future connections. If the key does not match, then the client assumes he has never connected to this server before and prompts for permission to add it. If the public key does match, it is used to decrypt the exchange hash signature. In turn, the result is then compared to the client's own hash value for the same group of concatenated puzzle pieces. In the event that there is a match, the client concludes with strong certainty that a) the server possesses the private key that is paired with a pre-authorized public key and b) the server must know the value of shared secret k. At this point, the server has been authenticated.

It would be mighty dangerous if the client failed to check for an existing public key in it's known_hosts file. Consider the repercussions over an example. Assume an attacker compromises .12, and then sabotages DNS so that .11's DNS name now points to .12. He can now cause .14 to try logging into the wrong machine. Upon connecting, if the host key provided by .12 is not already in known_hosts, the client should produce a banner that warns of potential attack (mitm or redirection). However, if this check was not conducted and password authentication was enabled, the user at .14 would then unknowingly enter his credentials into the compromised .12 system, where the attacker could capture it. Since the server is the first one with an opportunity to exploit a trust relationship, the protocol was designed with these checks so that the client can properly authenticate the server first.

If the server's public key was not in known_hosts upon connection, a user would see the following error (or something similar - it can be personalized):

So back to the real example at this point all the required information for key generation has been negotiated. Using the shared secret, exchange hash, and session ID (which is the initial exchange hash), the peers calculate keys for the following purposes:

Section 3

SSH2_MSG_NEWKEYS (packet 12)

Once the above operations are complete, the client sends it's SSH2_MSG_NEWKEYS message to the server. This is a notice that keying materials and algorithms should go into effect from this point on. Here is the client-side debug output:

During the SSH session, either side can invoke a rekeying procedure. The RFC draft recommends this be done once per GB of data transferred or hour of activity, whichever comes first. This would make it more difficult for an attacker to obtain enough ciphertext to attempt cryptanalysis. It also prevents the 32-bit sequence number (a value used in MAC generation) from wrapping around back to zero, which would cause replay-attack vulnerabilities. The sequence number itself is never sent across the network, it is simply known by both peers based on how many messages have been exchanged.

Section 4

Once an encrypted transport layer is established and identity of the server is verified, the client must authenticate. If you had doubts on why the server must be authenticated first, now it makes sense. If the client authenticates first then it would either do so in plain text or it would send credentials to a server it isn't familiar with (and thus shouldn't trust).

Requesting SSH_AUTH

Public Key Authentication

Since this document is focused on the cryptography of SSH2, only public key will be discussed in this section. The process is similar to how the server is authenticated using (public) host keys in section 2. A signature is created by concatenating several pieces of information known by both peers (strings, byte, and Boolean types in this case). The client then signs this data with the user's RSA or DSS private key. This resulting value is sent to the server along with the user's public key so the signature can be verified. If this checks out, then the client is believed to posess the private key of the corresponding public key sent in the packet; however this is only part of the login process. The more important aspect is confirming that the user who posesses this key pair is actually authorized to log in.

The SSH-AUTH module does not dictate how the later aspect should be conducted, rather it leaves this up to the particular implementation. The most common technique is to locate the users's advertised public key in the local users' authorized_keys file (~/.ssh/authorized_keys). This means each user who intends to authenticate via public key must have prior access to the server in order to plant the public key, which can be a considerable amount of work if many servers need to be accessed. This is why the solution is left up to the implementation - a centralized source such as an LDAP database or PKI key server can be queried for this information.

Aside from the cryptography, there are many other ways to satisfy a server's authentication requirements (assuming the server offers more than just the public key method) and even more ways to authorize a user's actions. Authentication is not the same as authorization. For example, a user might pass authentication (ie s/he is who s/he claims to be), but fail authorization (ie s/he is only allowed to run certain commands remotely). SSH2 can enforce rules such as where a user logs in from, commands s/he can execute; if X11 forwarding, port forwarding, or psuedo-terminals are allowed; and it can even chroot users to specific directories. At this point, SSH-CONN is normally invoked to handle the pty, multiplexing, and launch subsystems (sftp).

Section 5

From the given information, it's evident that the security of SSH2 is based just as heavily on the security of underlying cryptosystems as it is on user interaction. If a user exposes his password and/or private key, the use of strong cryptography is wasted. Likewise, if a server supports weak algorithms and allows SSH1, a user can be as careful as possible, but the total system is still relatively insecure. In this section, some best practices will be discussed so administrators can choose what is right for their environment.

Passwords vs Public Keys

If password authentication is chosen as a standard, then the only credentials used to authenticate a user are sent (encrypted, of course) across the network from client to server. If public key authentication is chosen, neither the private key nor the associated passphrase leave the client. So, on one hand, the only piece an attacker needs is transmitted; and on the other hand neither piece is transmitted. At first glance, it might seem like a simple decision, but there is much more.

Password aging can easily be enforced on the server where SSH runs, while key pairs are less likely to be changed at regular intervals. If an attacker obtained a private key, he would be able to access the server for a much longer period before a switch locked him out. If a central source such as LDAP or PKI was available, key pairs could change more frequently without much work; but this isn't always possible.

Attackers wishing to circumvent security by sniffing a password would have to stage a mitm or similar type of attack. One option discussed earlier involves DNS redirection to a server capable of logging keystrokes. Even then, an adversary would need to wait until the user attempted to login and hope that the server authentication warning is ignored. Remote brute force is also an option, but extremely noisy and requires a presense online, which in easier to detect. This makes password sniffing and guessing difficult.

Furthermore, a private key can be brute forced off-line if it is encrypted with a passphrase, and no one would know it was being conducted. This is assuming the private key is actually encrypted like it should be, which might be hard to manage and enforce. This type of attack of course would not be possible without somehow gaining access to a user's private key file. Likewise, if an attacker first gains access to a shadow or SAM database, passwords can be brute forced off-line just as easily.

The immediate solution is to apply complexity requirements for the password or passphrase. Users are always resistant to choosing complex passwords, because they're difficult to remember, but at least an operating system can enforce a policy (ie via PAM) for passwords, whereas this is not so easy with key pairs.

Password authentication and public key authentication both utilize cryptography, but in different ways. Using public key, a server dictates the supported algorithms for creating the keys. SSH2 requires DSS and recommends RSA. It will not accept use of any less secure algorithms without custom configuration, however DSS and RSA happen to be quite strong. In other words, it's relatively safe by default. Passwords on the other hand rely on mechanisms offered by the server operating system. Some modern installations still allow password hashing with algorithms based on DES, a completely intolerable system these days. A small number even select DES by default.

While this is certainly not an exhaustive list of pros and cons, it should get some ideas flowing. SSH2 is very flexible and does it's job well, but as previously warned - a small configuration error or weak cryptosystem could spoil all of it's goals.