(disclosure: i contribute to the monkeysphere project)
> The critical feature of the SSH trust model is that it has no trust
> model. It is entirely up to the user to verify the key. For a capable
> user, this is no problem, because such a user knows how to verify a key
> out of band. For the unskilled user, this method is still better than
> any other alternative, because it involves the least complexity. The
> concept of "store this key please, and notify me if it ever changes" is
> a lot easier for average users to understand than anything involving
> certificates or webs of trust.
You are right that this method is uncomplicated, however it encourages users to "click through" and fail to verify in the same way that people click through SSL certificate failure windows in their browser. This is bad behavior reinforcement. All too often the most capable users fail to verify keys out of band, and just type "yes" at that ssh host-key prompt so they can get to the machine. The number of admins that I know who accept a ssh host key fingerprint without verifying it are frighteningly low. Even fewer admins make those fingerprints available to others via a cryptographically verifiable mechanism. The reasons why capable people don't do this are varied, but one reason might be that it is not obvious where or how you should check this fingerprint. The fact that so many people accept these host keys without verification because there is no clear way of doing that verification is a problem.
Likewise, if you have verified the FP of a host key, and then it does change because the admin had to re-key (perhaps as the result of a routine rebuild of the box). Next time you connect, you will be presented with the ssh Big Scary Warning(tm) and you will need to remove that host key, find out what happened and then verify a new host key before you can continue. This is a good thing, although annoying to have to deal with when the re-key was done on purpose by the correct people running the machine and if you have no reliable method of verifying that this new host key is the right one and that this change should have happened.
Both the scenario of a user connecting to a machine for the first time and being asked to verify a host key, as well as the scenario of the admin needing to re-key the machine are made smoother by the use of the Monkeysphere because it makes the mechanism more simple, more clear and now only presents you with these questions when absolutely necessary. This reduces the "click through" reinforcement and raises the importance of those messages, as they appear only when something is wrong. The user is now *only* prompted to confirm a host-key fingerprint if they have no mechanism of trust to verify the key, or if there is an actual man-in-the-middle. The admin can do a re-key and re-certification smoothly, without freaking out the end-users.
djao also said:
> I view MonkeySphere in the same category as VeriSign and other
> companies trying to extort money from users for providing
> inferior security. They are worse than a solution in search of a
> problem. They are actually creating new security problems where
> none existed before, in the name of profit.
Clarification: Monkeysphere is *not* a profit-driven enterprise. It is not a company, and it is not involved in extortion of money. The Monkeysphere is a free software project, just a few regular folks getting together to hack, in the name of freedom, not profit.