Chris's Wiki :: blog/sysadmin/LittleScriptsVIII Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/LittleScriptsVIII?atomcommentsDWiki2011-12-20T18:37:33ZRecent comments in Chris's Wiki :: blog/sysadmin/LittleScriptsVIII.By Chris Siebenmann on /blog/sysadmin/LittleScriptsVIIItag:CSpace:blog/sysadmin/LittleScriptsVIII:dc9e89fd5676fd41409291a7f1ed7208110e98d6Chris Siebenmann<div class="wikitext"><p>Your comment made me curious so I went digging. The short version is
that as far as I can tell, public key auth blocks effective man in
the middle attacks; if there is a MitM, your public key will fail to
authenticate. The full explanation is long and complicated enough to
be an entry, <a href="https://utcc.utoronto.ca/~cks/space/blog/tech/SshAndMitM">SshAndMitM</a>.</p>
<p>(You can impersonate a server even without knowing my public key
at all; you just accept whatever signature I claim as valid. But
the tricky bit is getting me authenticated to the real server while
you sit in the middle, reading the conversation.)</p>
</div>2011-12-20T18:37:33ZFrom 71.179.165.244 on /blog/sysadmin/LittleScriptsVIIItag:CSpace:blog/sysadmin/LittleScriptsVIII:d204039ed5c8c1d6da99e7f9ae783c2d07af0caeFrom 71.179.165.244<div class="wikitext"><p>A warning about 'StrictHostKeyChecking no' by default. I had the same thought as you did, and tested the behavior. When set to 'no', ssh will connect anyway if the host key changes and you're using public key auth (it will print a warning, and disable password based auth however), which doesn't prevent a man in the middle attack if the person has access to your public key (which it's very likely they will have).</p>
<p>From what I can tell, there is no way to have ssh automatically 'Trust on first use' - assume you answer 'yes' to the initial query, but then refuse to connect if the host key ever changes. It's a shame, as this would be ideal behavior for automated scripts that use ssh.</p>
<p>Mark</p>
</div>2011-12-20T15:51:41Z