There’s a lot more happening under the hood – Deep Dive SSH Protocol Version 2
SSH protocol version 2 is the default protocol used these days. Most modern operating systems now a days by default select SSH version 2 for login and they switch to SSH version 1 in case version 2 is unavailable.
From first point in the below table, multiple functions like authentication, key exchange and encryption were part of a single protocol in SSH version 1 due to which it was sometimes called as “One monolithic protocol”. However, in SSH version 2, these functions are implemented in different protocol and once we combine all those protocols, we get a suite of SSH protocol version 2.
Difference between versions 1 and 2 of the SSH protocol.
|SSH protocol, version 2||SSH protocol, version 1|
|Separate transport, authentication, and connection protocols||One monolithic protocol|
|Strong cryptographic integrity check||Weak CRC-32 integrity check; admits an insertion attack in conjunction with some bulk ciphers.|
|Supports password changing||N/A|
|Any number of session channels per connection (including none)||Exactly one session channel per connection (requires issuing a remote command even when you don’t want one)|
|Full negotiation of modular cryptographic and compression algorithms, including bulk encryption, MAC, and public-key||Negotiates only the bulk cipher; all others are fixed|
|Encryption, MAC, and compression are negotiated separately for each direction, with independent keys||The same algorithms and keys are used in both directions (although RC4 uses separate keys, since the algorithm’s design demands that keys not be reused)|
|Extensible algorithm/protocol naming scheme allows local extensions while preserving interoperability||Fixed encoding precludes interoperable additions|
|User authentication methods:
||Supports a wider variety:
|Use of Diffie-Hellman key agreement removes the need for a server key||Server key used for forward secrecy on the session key|
|Supports public-key certificates||N/A|
|User authentication exchange is more flexible, and allows requiring multiple forms of authentication for access.||Allows for exactly one form of authentication per session.|
|hostbased authentication is in principle independent of client network address, and so can work with proxying, mobile clients, etc. (though this is not currently implemented).||RhostsRSA authentication is effectively tied to the client host address, limiting its usefulness.|
|periodic replacement of session keys||N/A|
SSH version 1 is very much limited in its support for wide range of algorithms that can be used for session key exchange, message authentication codes, compression algorithms etc. SSH 2 gives pretty good number of choices for the client to select from. SSH version 2 even has a space for adding your own custom algorithm.
During our discussion regarding session key in the previous blog on SSH v1 (which is the symmetric key used for encrypting the complete session ), we saw that the client after selecting one algorithm from the list of supported by the server, generates a symmetric key and sends it to the server with double encryption(first encryption with the server host key and then with the server key, which keeps on changing every hour). In ssh version 2, there is no concept of server key. Instead it the server provides with the list of supported key exchange methods, from which the client selects one. As of now ssh version 2 works on diffie-hellmangroup1-sha1 for exchanging keys. I will recommend reading the below article of Wikipedia, to get an idea about diffie-hellmangroup1-sha1.
The basic idea behind this change is that no single party(client or the server), should decide the session key. All the supported key exchange algorithm that will be added in the future, will consist this property(nieigther server nor the client can dictate the session key)
So there is no concept of server key (which is altered every hour) in ssh version 2.
The second major change in SSH version 2 is the inclusion of a concept called as certificate authority(CA), who will sign the public key’s used in the communication. This is exactly the same method used in SSL. However this is never implemented in real world as of now. But the protocol has already a room made for this.
Message authentication code’s are used in any secure communication to verify the integrity of the message. Even SSH version 1 uses a message authentication code called as CRC-32(Cyclic Redundancy Check). CRC although does check alteration in data, but is not considered best when security is a major concern. SSH 2 uses advanced encryption standard based MAC. Some of the supported ssh 2 message authentication codes are as below.
Rekeying of session key
SSH includes an added functionality called as rekying of the session key. What happens is, previously in ssh version 1, only one session key was used for the entire session. These days, almost all activities are carried out by ssh session. I myself login to a remote server, and leave that session as it is for weeks together, to continue from where i left.
In such login ssh session’s its better to change the session key without breaking the session. That’s a feature in ssh version 2.
let’s now have a summary of the differences between ssh version 1 and ssh version 2
- Diffie-Hellman key is used instead of the server key for sharing the session key in version 2 protocol
- No Rhosts support in ssh 2
- SSH protocol version 1 only allows negotiation of the symmetric encryption algorithm, all other things are hard corded(mac, compression etc)
- SSH 2 supports certificates for public keys used
- SSH 2 server can dictate the client to use multiple authentication methods in a single session to succeed. However ssh version 1 only supports one method per session
- SSH version 2 allows the change of session key periodically.