Support for multiple keys per network name

Advertisement

ergarbos
Guest

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.

Reply with quote

Advertisement

ergarbos
Guest

Re: Support for multiple keys per network name

Hmmm... I was having issues getting this to work in my testing via script, but now that you clarified the "Add" button takes care of this, I went through a connection manually and tried this. Sure enough, answering "Add" does add this to the .ini file I'm using, where I was then able to view the correct syntax and with further testing confirm this is working as desired.

This would be great to add in detail to the Documentation/FAQ. I think this is a great enhancement to the capabilities of your product, and with some publicity I bet many more sysadmins with cluster/load-balancer hostkey issues would be happy to take advantage of this.

Sharing my experience...
1) I manually copied the node1 hostkey to a second line in my .ini file, changing the hostname from node1 to the name of the load-balanced virtual IP.
rsa2@22:node1=0x<<first long string of characters>>
rsa2@22:node2=0x<<second long string of characters>>
rsa2@22:clustervip=0x<<first long string of characters>>

2) I connected manually. The first time it happened to go to the node with the matching key, and succeeded. The second time, it went to node2 and threw an error. I hit "A" for "Add" and it continued to connect.
C:\Program Files (x86)\WinSCP>winscp.com /ini=workdir\WinSCP.ini /log=workdir\logfile.txt
winscp> open sftp://user:pass@clustervip
Searching for host...
Connecting to host...
Authenticating...
Using username "user".
Authenticating with pre-entered password.
Authenticated.
Starting the session...
Session started.
Active session: [1] user@clustervip
winscp> close
Session 'user@clustervip' closed.
No session.
winscp> open sftp://user:pass@clustervip
Searching for host...
Connecting to host...
Authenticating...
WARNING - POTENTIAL SECURITY BREACH!
The server's host key does not match the one WinSCP has in cache. This means that either the server administrator has changed the host key, the server presents different key under certain circumstance, or you have actually connected to another computer pretending to be the server.
The new rsa2 key fingerprint is:
ssh-rsa 2048 <<key fingerprint...>>
If you were expecting this change, trust the new key and want to continue connecting to the server, either press Update to update cache, or press Add to add the new key to the cache while keeping the old one(s). If you want to carry on connecting but without updating the cache, press Skip. If you want to abandon the connection completely, press Cancel. Pressing Cancel is the ONLY guaranteed safe choice.
(U)pdate, (A)dd, Ca(n)cel, (C)opy Key, (S)kip: Add
Using username "user".
Authenticating with pre-entered password.
Authenticated.
Starting the session...
Session started.
Active session: [1] user@clustervip
winscp> close

3) I viewed the .ini file and noticed the change. The keys are simply put together on the same line of the file separated by a semi-colon.
rsa2@22:node1=0x<<first long string of characters>>
rsa2@22:node2=0x<<second long string of characters>>
rsa2@22:clustervip=0x<<first long string of characters>>;0x<<second long string of characters>>
Depending how you're viewing this and how the very long lines wrap, this should be readily obvious as twice as long as a normal hostkey entry.

4) Repeated testing confirms that I can now connect through the VIP to either cluster node via automated scripting without hostkey errors. Huzzah! :)

Thanks Martin. Great work.

Reply with quote

Advertisement

You can post new topics in this forum