With a solid understanding of the current SSH protocol behind us, we now quickly summarize SSH-1 in terms of its differences, weaknesses, and shortcomings in comparison with SSH-2:
SSH-1 is defined as a single monolithic protocol, rather than the modular approach taken with the SSH-2 suite.
SSH-1 has more fixed parameters; in fact, only the bulk cipher is negotiated. The integrity algorithm, host key type, key-exchange methods, etc., are all fixed.
SSH-1 lacks the well-defined naming syntax for SSH-2 entities which allows for smooth, implementation-specific extensions.
SSH-1’s user authentication process allows only one method to succeed; the server can’t require multiple methods.
SSH-1’s RhostsRSA authentication, analogous to hostbased, is in principle limited to using a network address as the client host identifier. This limits its usefulness in the face of network issues such as NAT, proxying, mobile clients, etc.
SSH-1 remote forwarding specifies only a port, not a full socket, so can’t be bound to different addresses on multihomed servers, and the gatewayhosts option must be set globally for all remote forwardings rather than per port.
SSH-1 uses a weak integrity check, the CRC-32 algorithm. CRC-32 is not cryptographically strong, and its weakness is the basis of the Futoransky/Kargieman “insertion attack”; see http://seclists.org/lists/firewall-wizards/1998/Jun/0095.html.
The fixed key exchange of SSH-1 employs an extra asymmetric key called the server key, not to be confused with a host key. [3.6.1] The server key is an ephemeral public/private key pair, regenerated once per hour and used to provide forward secrecy for the session key. Forward secrecy means that even if long-term secrets such as user or host private keys are compromised later, these can’t be used to decrypt SSH sessions recorded earlier; the use of an extra key which is never written to disk assures this. The Diffie-Hellman algorithm which is the basis of all the SSH-2 key exchanges provides forward secrecy by itself, and so an extra “server key” is not needed.
The SSH-1 key exchange is weak in that the client alone determines the session key, and simply sends it to the server. A Trojaned client can easily use weak keys to compromise all its sessions undetectably.