| 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:- publickey (DSA, RSA*, OpenPGP)
- hostbased
- password
- (Rhosts dropped due to insecurity)
| Supports a wider variety:- public-key (RSA only)
- RhostsRSA
- password
- Rhosts (rsh-style)
- TIS
- Kerberos
|
| 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 |
