I am thinking about the following solution to the issues pointed out by David Mazieres. These changes propose solutions to the following problems: - replay of password-authenticated sessions - corrupt server can use RSA authentication to log into another server When the client receives SSH_SMSG_PUBLIC_KEY, it computes a 128 bit (16 byte) value by converting the modulus of the public key into a stream of bytes, msb first. The cookie sent by the server is appended to this stream. Both sides compute the MD5 of the resulting stream. This value will be called the "session id". In the SSH_CMSG_SESSION_KEY message, the first 16 bytes of the session key (before encryption) are xored with the 16 bytes of the session id. This does not reveal plain text from the RSA-encrypted part, but binds the encrypted session key to a specific cookie and server. This should eliminate the possibility of replay, because the cookie is unique for each connection. In all SSH_CMSG_AUTH_RSA_RESPONSE messages (used both in user and client host authentication), append the session id to the decrypted challenge before computing MD5. The MD5 is computed from the resulting 48 bytes. This makes the response bound to the server cookie and the server key, and should elinate using the same response for another server. (Faking the server key is hard, because the client verifies that it matches the one stored in its database.) If a server supports this revision of the protocol, it reports its protocol version as 1.1. If the server protocol version is 1.0, the client displays a warning (recommending to update server software) and uses the old protocol for compatibility. The client reports the protocol version that it will use. The compatibility code will be removed in a later release. (The changes are easy to implement compatibly.) I would like to receive comments on this. Tatu