Steve, > On the first connection, it doesn't help and SSH is vulnerable to the > MITM attack. The link above mentions this, but doesn't really draw > your attention to it. ;-)
It is the holy truth. That is the reason for distributing the public keys of servers to the clients via some off-line methods. <slight offtopic> and that is the problem that was tried to be solved by X.509 certificates: the trusted entity (CA) signs the public key and it is up to the client to verify the signature. Surely this just offloads the problem to the CA public key distribution to clients. But it is easier to propagate one CA public key than all public keys signed by that CA. But this scheme is not much applicable to SSH. </slight offtopic> > However, SSH stores the host key in the "known_hosts" file so it > doesn't need to ask for it on subsequent connection attempts. The SSH > protocol has a mechanism whereby the client sends something (its > "challenge") encrypted with the public key for that server. The > server decrypts it and sends an appropriate "response" back to the > client. This lets the client know for certain that the server is the > same one as recorded in known_hosts. The MITM can't decrypt the > challenge so it doesn't know how to respond. > > I've simplified this quite a bit, but I hope this is enough to answer > your question without getting too confusing. ;-) Please, read the RFC 4253 and do not oversimplify the things: there is no challenges in establishing the initial shared secret in SSH transport layer. -- Eygene
