On 11/05/07, Jamis Buck <[EMAIL PROTECTED] > wrote: > > > Chris, > > I wonder if there might be a better way to do this. Your patch > basically emasculates the whole point of host-key verification: if > the key differs, things should blow up, otherwise there is the danger > of a "man in the middle" attack.
I'm not sure it does do that -- that's certainly not my intention. The idea is that we find all the keys that should match (by host, ip, port *and* type), then look for a match, blowing up if there isn't one. If you have an RSA key for a server, and it gives you a different RSA key, things still blow up with my patch applied. What happens with 1.1.0 is that we ignore the type until it's too late -- we're treating "we have a key for this server, but it's the other type" as if it was "we have a key for this server, which *should* match, but it doesn't". Perhaps we could raise a different exception for this situation, and the caller can deal with it differently to a genuine host key mismatch? Now, if your server has both an RSA and a DSA key, maybe a way needs > to be found so that Net::SSH chooses the correct key (or passes both > to the host key verifier somehow). I'm not sure either of those > options are actually feasible (it's been a long time since I've been > in that neck of the Net::SSH woods), but it might be educational to > look at how openssh works in this situation. OpenSSH's behaviour here is to warn that you have a key that doesn't match -- but that it's OK, because you wouldn't expect a DSA key to match an RSA key. It then allows you to accept the new key, in the same way as accepting a key for a completely unknown host. Chris. --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
