EDIT: Nevermind, I see that it was fixed in 5.2 but the current download is only 5.1.x. Thanks!

I have been going through the latest WinSCP .NET DLL using the object browser, but I can't seem to find anything about implementing the fix from bug #815.

I want to be able to display the hostkey to the enduser and have them verify that it matches the one provided (and I will then store it for later verification,) rather than worrying about having our end users formatting that information properly, and likely failing/causing a ticket to be open to me.

It looks like there was an event added that would allow this functionality? Any pointers on where that event is located in the DLL?

Thanks for implementing the fix, Martin.

martin wrote:

So why are you using SFTP at all? Accepting any hostkey breaks the security. You can use plain FTP instead.

Because I use Azure to create servers and I need to logon for the first time.

Other way to solve this is like they have done for sshj for JAVA:

https://www.javadoc.io/doc/com.hierynomus/sshj/latest/net/schmizz/sshj/transport/verification/PromiscuousVerifier.html

Hello, any idea on the schedule when this feature would be added?
I'm looking for the same solution as the questions here...

Event to accept an unknown host key

Thanks a lot,
Frank

I have added topic to the FAQ:
Where do I get SSH host key fingerprint to authorize the server?

To encrypt anything, you need to exchange the keys. Without knowing that you are exchanging the keys with the actual server (the host), you might end up exchanging keys with an attacker. So if you do not verify the host key, you are potentially encrypting the stream using forged key owned by the attacker. So the attacker can decode the stream.

This is analogous to a web user accessing a web page via HTTPS. Only the server end of that connection is authenticated via protocol. The client end is generally not.

With SSL, you have certificate chain, so you get a warning, if the certificate is not backed by trusted authority. There's nothing like that with SSH.

Using SFTP just to encrypt a stream is a perfectly legitimate use case.

Encrypting the traffic is useful, not useless, independent of endpoint authentication.

Looking at responses on this thread, it appears this [authenticate one endpoint only] use case is more popular than the mutual authentication the library currently enforces?

This is analogous to a web user accessing a web page via HTTPS. Only the server end of that connection is authenticated via protocol. The client end is generally not.

We to need the ability to (via .net) accept the host key automatically. Most people using this connection are at the "whim" of the company hosting the server. Yes there is no protection against spoofing, but frankly 99% of the time these keys are not "shared" anyway. They are only sent during the handshake of the connection process.

This will probably prevent us from using this :(

Hi, yes the new .NET assembly is a great idea

We are looking for using Automation so would need the ability to handle the unknown hostkey event so if you could add this that would be very useful.

The use case in our situation is that we wish to scan unix systems using SNMP then switch to SCP to download various configuration files for audit purposes. We wouldn't know the host key in advance.
<invalid hyperlink removed by admin>

I guess that SCP host key security is questionable anyway due to human intervention – whenever I've used WinSCP (which I have for some 10 years maybe?) I've never validated the server's HostKey on first connection... (blindly accepting whatever WinSCP says).

Thanks,
Dave

ironside wrote:

Accepting any host key compromises authentication but you still end up with an encrypted transfer, no?

Yes, with transfer encrypted using key of the attacker. Quite useless encryption.

Accepting any host key compromises authentication but you still end up with an encrypted transfer, no?

Perhaps John is only concerned about encrypting the data on the wire, less concerned with authenticating the endpoint?

So why are you using SFTP at all? Accepting any hostkey breaks the security. You can use plain FTP instead.

Anyway, I plan to add an event to implement custom way of verifying the host key:
Issue 815 – Option/Event to accept an unknown host key/certificate

That obviously can be abused to accept any hostkey :(

About a year ago, I used the WinSCP command-line interface for automating SFTP usage. I wanted to revise my code that used this so I checked out the site to see what changes might have been made. I was very happy to see that a .NET assembly is now offered, as it will save me a ton of time. It works great for me so far, however there is one big issue – being unable to automatically accept host keys. I used this option when using the command-line interface. We connect with many SFTPs, some of them change their key weekly. Manually keeping track of and storing keys, or manually accepting changes and setting Session.DefaultConfiguration to false in our code, would be untenable as the intent is for this code to run on a schedule without any user intervention. Being able to automatically accept host keys in the assembly would be great!