| 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 |
