Re: tunnel "security breach" bug
This has been resolved already. The fix will be included into the next release.
- martin
Post a reply
Before posting, please read how to report bug or request support effectively.
Bug reports without an attached log file are usually useless.
Topic review
- martin
Re: tunnel "security breach" bug
Good point :-) Thanks for letting me know.
- Guest
tunnel "security breach" bug
I am using WinSCP 4.0.4. I have seen this problem previously on 4.0.3.
If I connect to a server through an SSH tunnel, it will check the SSH host key of the destination server and offer to remember it. If I do, then it remembers it under 127.0.0.1 port 6000 in the registry.
If I then connect to a different server through an SSH tunnel, it will give the "WARNING - POTENTIAL SECURITY BREACH" stuff; whether or not this server's key has ever been remembered; and, if it has been remembered correctly, even though the fingerprint is correct. This makes sense because it is checking under 127.0.0.1 port 6000 again, as this is where it set up the tunnel to listen. And sure enough, if I say yes, I see in the registry that the key for 127.0.0.1 port 6000 has been changed.
Even though this makes sense at some level, I would prefer that when a connection is made through an SSH tunnel, that the host key stuff be associated the the final destination server and port, and not 127.0.0.1:6000. This will allow one to connect to multiple servers through tunnels without screaming warnings each time; and it will actually check the keys versus the other copy it has, which is a security benefit.
If I connect to a server through an SSH tunnel, it will check the SSH host key of the destination server and offer to remember it. If I do, then it remembers it under 127.0.0.1 port 6000 in the registry.
If I then connect to a different server through an SSH tunnel, it will give the "WARNING - POTENTIAL SECURITY BREACH" stuff; whether or not this server's key has ever been remembered; and, if it has been remembered correctly, even though the fingerprint is correct. This makes sense because it is checking under 127.0.0.1 port 6000 again, as this is where it set up the tunnel to listen. And sure enough, if I say yes, I see in the registry that the key for 127.0.0.1 port 6000 has been changed.
Even though this makes sense at some level, I would prefer that when a connection is made through an SSH tunnel, that the host key stuff be associated the the final destination server and port, and not 127.0.0.1:6000. This will allow one to connect to multiple servers through tunnels without screaming warnings each time; and it will actually check the keys versus the other copy it has, which is a security benefit.