Support for multiple keys per network name
Martin, In January 2008 you posted a comment "OK. The next version of WinSCP will allow storing of multiple keys for single host" (see https://winscp.net/forum/viewtopic.php?t=4167). I would like to know whether this has been pursued (my testing with the current version suggests not) and if not, request that this does get pursued.
I have seen several posts like the above looking for ways around hostkey conflicts in clustered environments. Invariably the first response is "this is bad, as it throws out most of the security SSL provides." I think the question needs to be rephrased, as that answer is to me a bit of an overreaction. On one hand, accepting ANY key is of course bad, I agree. On the other hand, only being able to accept ONE possible hostkey is very secure, but is a tricky limitation to work with in a clustered environment (multiple hosts with load-balance or failover behind a Virtual IP).
However, there is a compromise position: what we need to do is accept "any one of a short list" of known and trusted hostkeys (in many cases, just two). This still, I believe, preserves the core principles of SSL security, namely that we should only accept a known and trusted hostkey to avoid man-in-the-middle attacks. The difference is that we need just a tiny bit more leeway in that key matching, so it's not strictly black and white, "one key is good and all others are bad" logic. We would like to be able to match a couple possible hostkeys rather than only one... or put another way, WinSCP should not throw warnings of a hostkey change and error out IF the new key is ALSO known and trusted for the same hostname (which in this case would be a virtual/cluster name rather than an actual hostname). At its most basic, I would think this would just require the key lookup code (from registry or .ini file) iterate through the available list of known keys seeking a match, rather than only pulling up the first or last listing for the hostname and then trying to match it.
Ideally this could also be solved by sharing hostkeys between servers - great, if you plan for this during the initial server build, but not if this comes up later. Often it's not possible to make this change after the fact... automated server provisioning may include new key generation, security policies may prevent it, non-clustered servers may later need to become clustered, or SCP/SFTP requirements may not come into scope until much later. In such cases, retroactively changing hostkeys is painful, as any client that might have the key cached would have to be updated, and this can have a cascading effect across an enterprise.
It's been a while since 2008... maybe this has been considered and hit implementation challenges and I just didn't get the memo... or maybe it's already implemented and just requires a certain implementation I don't see in the documentation. If so a quick update would still be appreciated.
I have seen several posts like the above looking for ways around hostkey conflicts in clustered environments. Invariably the first response is "this is bad, as it throws out most of the security SSL provides." I think the question needs to be rephrased, as that answer is to me a bit of an overreaction. On one hand, accepting ANY key is of course bad, I agree. On the other hand, only being able to accept ONE possible hostkey is very secure, but is a tricky limitation to work with in a clustered environment (multiple hosts with load-balance or failover behind a Virtual IP).
However, there is a compromise position: what we need to do is accept "any one of a short list" of known and trusted hostkeys (in many cases, just two). This still, I believe, preserves the core principles of SSL security, namely that we should only accept a known and trusted hostkey to avoid man-in-the-middle attacks. The difference is that we need just a tiny bit more leeway in that key matching, so it's not strictly black and white, "one key is good and all others are bad" logic. We would like to be able to match a couple possible hostkeys rather than only one... or put another way, WinSCP should not throw warnings of a hostkey change and error out IF the new key is ALSO known and trusted for the same hostname (which in this case would be a virtual/cluster name rather than an actual hostname). At its most basic, I would think this would just require the key lookup code (from registry or .ini file) iterate through the available list of known keys seeking a match, rather than only pulling up the first or last listing for the hostname and then trying to match it.
Ideally this could also be solved by sharing hostkeys between servers - great, if you plan for this during the initial server build, but not if this comes up later. Often it's not possible to make this change after the fact... automated server provisioning may include new key generation, security policies may prevent it, non-clustered servers may later need to become clustered, or SCP/SFTP requirements may not come into scope until much later. In such cases, retroactively changing hostkeys is painful, as any client that might have the key cached would have to be updated, and this can have a cascading effect across an enterprise.
It's been a while since 2008... maybe this has been considered and hit implementation challenges and I just didn't get the memo... or maybe it's already implemented and just requires a certain implementation I don't see in the documentation. If so a quick update would still be appreciated.
