Because the CRC checksum can be modified, an attacker can intercept an SSH1 packet, modify the contents, then modify the CRC to match. When the packet is then retransmitted, from the attacker to the victim, the CRC integrity check will pass. This means that the attacker can make arbitrary modifications to the packet and the victim will be unable to detect them. For this attack to be successful, the client must be using the RC4 cipher, the server must allow the use of RC4, and compression must be not be used. Note that RC4 was disabled from SSH Communications Security's distributions in 1997.
Client accepts unknown host keys from the server.
M then forwards PubKeyS to C, where a warning dialog will be displayed to indicate that the host key for M has changed. If the victim at C ignores this warning and accepts PubKeyS, the client's SSH1 software will generate a session key SessKeyC, which is encrypted in PubKeyS so that only S can decrypt it. However, because C has chosen to disable encryption, this session key won't actually be used anywhere. Now M has an open SSH1 connection to S, but it still needs to authenticate itself. This operation is invariant to the session ID derived from S' public key material.