The authenticity of host 'delicious.cake.net (220.127.116.11)' can't be established.
RSA key fingerprint is 18:93:ea:38:81:84:ae:34:b4:56:0e:51:7c:28:ef:cd.
Are you sure you want to continue connecting (yes/no)?
How about a few bets? So many stupid things are said about security, more often than not by drastically overestimating importance of security measures to people... Should we try prediction markets instead? I haven't heard about any research on prediction markets with thought-experiment money, but they do work with both real and play money, so I'm accepting your though-experiment bets!
First, let's find a random ssh user trying to access delicious.cake.net or some other server. I bet they're not going to check the ssh key fingerprint. Instead, they'll just blindly type yes without thinking. What rates do you take?
A second bet. Let's find someone who did not bother to check the ssh key fingerprint. I bet they're not under any kind of man in the middle attack, and everything will be perfectly fine. What are your rates here?
And one more. Assume someone is under man in the middle attack. I bet they would be owned by some other channel anyway, and so ssh key fingerprint check wouldn't help them at all.
My initial guesses as for the rates are 100:1, 10000:1, 10:1. I bet 9000 internets on each one of the possibilities. Yes, I know this is ridiculous, but go on and offer counter-bets if you think I'm wrong.
Why the magical thinking?So assuming I'm right, and the ssh key fingerprint check is useless, why don't we turn it off, or at least provide an option of doing so? This silly question is asked even with EC2 instances, where the instance key is randomly generated, so it's impossible for you to know it; and the instance already has your public key, so hopefully man in the middle attack shouldn't be possible (unless ssh works in some perverted way where that's not enough).
I bet the process goes something like this - ssh developers realized that man in the middle attack is possible. So what were their options? First, they could bother with the public key infrastructure of some sort, but seriously, that would be too much work, both for them and for admins. Second, they could just accept the possibility of man in the middle on the first connection. Both options make sense.
But no - instead they did some magical thinking, and added a completely useless security ritual, a bit of security fairy dust that magically "makes things secure" even though in reality it does nothing other than annoying the user.
It's not ssh's fault really - we're all trapped between irrational belief in importance of security, and reality of most kinds of attacks never happening due to high cost and low benefit to attackers in absence of economies of scale. So instead of reevaluating our beliefs we implement useless security rituals like that. And they work! After all, I don't see any ssh man in the middle around, do you?