Re: Failed host key complaint despite identical keys being shown
I have sent you an email.
- 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
- nh2
Re: Failed host key complaint despite identical keys being shown
Thanks martin!
Running this, after some seconds of transferring I get a popup "Signature from server's host key is invalid" with detail message:
WinSCP has written 3 trace files of 1 GB each. Already the first trace file contains a relevant error:
(How) Should I send you this 1GB trace file? It zip-compresses to 30 MB.
Does a trace contain information that I need to redact first?
Thanks!
Running this, after some seconds of transferring I get a popup "Signature from server's host key is invalid" with detail message:
Authentication log (see session log for details):
Using username "jp".
Authenticating with public key "eddsa-key-20210629".
Authentication failed.
WinSCP has written 3 trace files of 1 GB each. Already the first trace file contains a relevant error:
[19:16:02.837] [2074] [SecureShell.cpp:1690:TSecureShell::LogEvent] [Signature from server's host key is invalid]
[19:16:02.837] [2074] [SessionInfo.cpp:944:TSessionLog::Add] [Signature from server's host key is invalid] [5DABD38]
(How) Should I send you this 1GB trace file? It zip-compresses to 30 MB.
Does a trace contain information that I need to redact first?
Thanks!
- martin
Re: Failed host key complaint despite identical keys being shown
I'm sending you an email with a development version of WinSCP to the address you have used to register on this forum.
- nh2
Likely connected with this, I also observe WinSCP uploading files with corrupted contents.
The sizes match, but the MD5 hashes do not match after upload.
The difference isn't even at the end -- the end is exactly identical.
Sections in the middle of the file are zeroed out:
The sizes match, but the MD5 hashes do not match after upload.
The difference isn't even at the end -- the end is exactly identical.
root@myhost ~ # diff -u <(xxd < 006-second-transfer.e57) <(xxd < 006.e57)
Sections in the middle of the file are zeroed out:
-189658e0: e03d f1f0 f03d 8180 003e f9f8 f83d e9e8 .=...=...>...=..
+189658e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
- nh2
Having upgraded to 5.19.2, this is a stacktrace I get for the "Out of memory" error:
[/code]
Stack trace:
(00C55797)
(00FBC612)
(00FBE67A)
(00FBB434)
(0008544F) ntdll.dll
(00072A01) ntdll.dll.KiUserExceptionDispatcher
(00C084FB)
(00BF3C76)
(00BF3D69)
(00D35974)
(00D34857)
(00D31D32)
(00D8594A)
(00D870CC)
(00DB2A5B)
(00DB0C0A)
(00DB18FD)
(00DDAF4B)
(00DD98B8)
(00DD96E5)
(00DA50B6)
(00DD83B9)
(00CEEB93)
(00CED526)
(00CEC556)
(00CEA89C)
(000C16E3)
(0001F417) KERNEL32.DLL.BaseThreadInitThunk
(000662FB) ntdll.dll.RtlGetAppContainerNamedObjectPath
(000662C8) ntdll.dll.RtlGetAppContainerNamedObjectPath
- nh2
After clicking "Cancel" on the password prompts a sufficient number of times, WinSCP shows "Out of memory", even though the machine has 40 GB free RAM of 64 GB total; see screenshot.
Some thing seem to be going quite wrong here.
Some thing seem to be going quite wrong here.
- nh2
Failed host key complaint despite identical keys being shown
Hi,
I'm having a problem where sometimes, apparently nondeterministically, WinSCP claims thta the host key verification fails, even though the Ed25519 host key fingerprint it shows as "new" is exactly the same as the one it has saved.
Please see the attached screenshot, which displays that in fact the two keys are the same.
The key also agrees with what the server's fingerprint actually is.
The problem happens when doing large batch transfers of 100 GB toal with ~1GB individual file size, "background transfer" is active, and up to 9 files are being transferred in parallel.
If I click "Update", I get the "Host is not communicating for more than 15 seconds", with an "Abort" button that counts down seconds that reset from 57 back to 60 every 3 seconds approximately. Eventually, the Abort button will not have a seconds counter any more, and just be labelled "Abort", when I click that, I get a password prompt popup, even though I have configured the Site in WinSCP to use key-based login.
WinSCP 5.19 (Build 11512) on Windows Server 2019. Target host is openssh-8.2p1.
This looks like a bug to me.
I'm having a problem where sometimes, apparently nondeterministically, WinSCP claims thta the host key verification fails, even though the Ed25519 host key fingerprint it shows as "new" is exactly the same as the one it has saved.
Please see the attached screenshot, which displays that in fact the two keys are the same.
The key also agrees with what the server's fingerprint actually is.
The problem happens when doing large batch transfers of 100 GB toal with ~1GB individual file size, "background transfer" is active, and up to 9 files are being transferred in parallel.
If I click "Update", I get the "Host is not communicating for more than 15 seconds", with an "Abort" button that counts down seconds that reset from 57 back to 60 every 3 seconds approximately. Eventually, the Abort button will not have a seconds counter any more, and just be labelled "Abort", when I click that, I get a password prompt popup, even though I have configured the Site in WinSCP to use key-based login.
WinSCP 5.19 (Build 11512) on Windows Server 2019. Target host is openssh-8.2p1.
This looks like a bug to me.