Chris's Wiki :: blog/tech/SshAndMitM Commentshttps://utcc.utoronto.ca/~cks/space/blog/tech/SshAndMitM?atomcommentsDWiki2011-12-20T21:43:38ZRecent comments in Chris's Wiki :: blog/tech/SshAndMitM.By Chris Siebenmann on /blog/tech/SshAndMitMtag:CSpace:blog/tech/SshAndMitM:f113e23638e8056d24aeeb4123b83f73b0996892Chris Siebenmann<div class="wikitext"><p>I agree with you in general; impersonation is a potentially serious
issue for anything that automatically pushes or pulls sensitive data.
In general there is no easy solution to this; if you need to authenticate
both ends, you have key management issues. In ssh I think the best you
can do is insist on valid host keys and set them up by an out of band
mechanism.</p>
<p>(This is kind of what we do here for stuff where we care enough.)</p>
</div>2011-12-20T21:43:38ZFrom 71.179.165.244 on /blog/tech/SshAndMitMtag:CSpace:blog/tech/SshAndMitM:b7e016446f37fdeb733ac43603d4db3152679f84From 71.179.165.244<div class="wikitext"><p>I stand corrected, and I never thought about a rogue server just accepting whatever you pass to it, meaning you don't need to have your public key available.</p>
<p>In my case, I'd still be concerned about disabling strict host key checking by default because of the possibility of someone impersonating the server you intend to connect to - bad things could happen if you expect to be sending sensitive data (e.g. a regular rsync cron job), but I agree that it's a lot less severe than a true MitM attack.</p>
<p>Mark</p>
</div>2011-12-20T20:44:10Z