ssh client is suppose to honor

PasswordAuthentication no
Protocol 2
StrictHostKeyChecking yes

so that it becomes even harder (explicit effort) to override and fallback to password.

note that PKI was designed to address first time communication between strangers ... where the relying party has no other mechanism for authenticating the stranger (i.e. the offline email scenario from the early 80s ... where relying party dialed local electronic post office, exchanged email and hung up ... this is the analogy to the letters of credit/introduction from the sailing ship days).

PKI doesn't actually make initial key distribution/exchange issues disappear ... they are simply obfuscated under layers of complex, expensive protocols and business processes. First off, the certification authority(s) public key has to be securely distributed to the relying parties (in a trusted manner). Most existing implementations involve certification authority public keys being included in some application distribution (and end-users have to trust that the correct keys were included in the application build and were never subsequently compromised before coming into their possession).

Then the digital certificates that are created by certification authorities ... need a trusted registration authority process ... where individuals and/or systems reliably transmit their keys to the registration authority. the registration authority then has to vet these keys before the digital certificates are created and returned.

All of these (mostly obfuscated) PKI processes don't fundamentally differ with what would happen in a purely SSH scenario (aka a remote server new key acceptance is on par with what would be needed to accept a new certification authority key or a certification authority checking out a key pursuant to creation of new digital certificate).

Any claims that the SSH model couldn't work implied that fundamental, underlying PKI implementations also couldn't work ... once the enormous obfuscating PKI business processes, costs, and complexity were stripped away.

Not to spoil your party, but a compromised SSH installation is hardly an MITM attack. Less the incompetence on the attacker's side, you were thoroughly screwed the moment you entered "yes" on that prompt to accept the changed host key (because, had this been MITM, Mallory would have forwarded the original host's authentic request for your private key, you would have authenticated, and they would have 0wned your session).

Not sure if you've arrived at the party as yet :) it indeed wasn't an MITM attack, as it says in the conclusions!

It was something far far worse: the machine was compromised by the attacker. The attacker already owned the machine, and used that to acquire something else, again more important than a simple 0wned session: passwords.

If the best attack against SSH is to take over the node, then that's good news for SSH, as it is secure enough. Question then is can we expand SSH to also protect more of the node?

iang

Another observation ... it has been pointed out that the sysadms involved worked as a team, and it was only the combined actions of the team that detected the compromise. That's less good news for the model.

"Remember: the threat is on the node. The wire is (relatively) secure."

I would say they are about equal. We see a lot of phishing, and a lot of script attacks to guess passwords.

We know how to fix the node - the specifications for Bitfrost are a summary of current (unapplied) wisdom.

I don't think most people have grasped what is required to fix the network. On reflection, I need to set up a web page explaining the problem, and what is needed to fix it. My last attempt to explain the problem resulted in considerable indignation.

"The use of the information known to me saved me in this case. This is a good example of how to use the principle of Divide and Conquer. I call this process "bootstrapping relationships into key exchanges" and it is widely used outside the formal security industry."

Trust ascends from below, like a crane, not from above like a skyhook. You don't trust Joe merely because Verisign informs you his true name is Joseph Melgow.

>Etc etc, you can see that this argument goes round and round,
>and will never be solved until we get some data.

I tried to get some data a while back on SSH key checking in response to SSH fuzzy fingerprints (if you're not familiar with fuzzy fingerprints, they create a close-enough fingerprint to the actual target to pass muster in most cases). Because human-subject experimentation requires a lot of paperwork and scrutiny, I thought I'd first try and establish a base rate for SSH fingerprint checking in general. In other words if you set up a new server with a totally different key from the current one, how many people will be deterred?

So I tried to establish the fingerprint-check rate in a population of maybe a few thousand users.

It was zero.

No-one had ever performed an out-of-band check of an SSH fingerprint when it changed.

Given a base rate of zero, I didn't consider it worthwhile doing the fuzzy fingerprint check :-).

So there is a form of data available, but because it's not very interesting it'll never be written up in a conference paper (there's a longer discussion of fuzzy fingerprints and related stuff in my perpetual-work-in-progress http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf). I've seen this type of authentication referred to as leap-of-faith authentication in a few recent usability papers, and that seems to be a reasonable name for it. That's not saying it's a bad thing, just that you have to know what it is you're getting for your money.

>So there is a form of data available, but because it's not very interesting
>it'll never be written up in a conference paper

Having said that, if anyone would like to accept the following short paper for a conference, let me know.

-- Snip --

Do Users Check SSH Key Fingerprints?
====================================
Peter Gutmann, University of Auckland

Abstract
--------
No.

-- Snip --

(I may have to include some references or something I guess).