I did this
This test failure from Cirrus CI shows test3021 failing:
curl: (60) Denied establishing ssh session: mismatch sha256 fingerprint. Remote ��z�i/XEa"��P�R��h�]���wl�q���)� is not equal to C:/msys64/Ad6smkvWEVhIs/nUM1S2fOjaL9djxb6d2zkcbQUgik
The error message is supposed to show two sha256 fingerprints in base64 format. The gibberish came from a printing mistake and I landed 3467e89 to fix it. The reason the match failed was not because of that but because one of the keys is C:/msys64/Ad6smkvWEVhIs/nUM1S2fOjaL9djxb6d2zkcbQUgik, note the erroneous C:/msys64/. There should be just a base64 string there.
Tracing it back I don't see anything unusual.
|
const char *pubkey_sha256 = data->set.str[STRING_SSH_HOST_PUBLIC_KEY_SHA256]; |
|
--hostpubsha256 %SSHSRVSHA256 --key curl_client_key --pubkey curl_client_key.pub -u %USER: sftp://%HOSTIP:%SSHPORT%SSH_PWD/log/file%TESTNUMBER.txt |
|
my $hstpubsha256f = "curl_host_rsa_key.pub_sha256"; |
|
if(!open(PUBSHA256FILE, "<", $hstpubsha256f) || |
|
(read(PUBSHA256FILE, $SSHSRVSHA256, 48) == 0) || |
|
!close(PUBSHA256FILE)) |
|
open(PUBSHA256FILE, ">$hstpubsha256f"); |
|
print PUBSHA256FILE sha256_base64(decode_base64($rsahostkey[1])); |
|
close(PUBSHA256FILE); |
I expected the following
My guess is this has something to do with msys2 path interpretation. Maybe the base64 string had a leading / and so msys2 converted that to C:/msys64/. There is an msys2 environment variable MSYS2_ARG_CONV_EXCL that can be set to stop msys2 from tampering with arguments. That is already done in appveyor configs, for example:
|
MSYS2_ARG_CONV_EXCL: "/*" |
I think that should be done for Cirrus CI as well.
I did this
This test failure from Cirrus CI shows test3021 failing:
curl: (60) Denied establishing ssh session: mismatch sha256 fingerprint. Remote ��z�i/XEa"��P�R��h�]���wl�q���)� is not equal to C:/msys64/Ad6smkvWEVhIs/nUM1S2fOjaL9djxb6d2zkcbQUgikThe error message is supposed to show two sha256 fingerprints in base64 format. The gibberish came from a printing mistake and I landed 3467e89 to fix it. The reason the match failed was not because of that but because one of the keys is
C:/msys64/Ad6smkvWEVhIs/nUM1S2fOjaL9djxb6d2zkcbQUgik, note the erroneousC:/msys64/. There should be just a base64 string there.Tracing it back I don't see anything unusual.
curl/lib/vssh/libssh2.c
Line 623 in 9e560d1
curl/tests/data/test3021
Line 27 in 9e560d1
curl/tests/runtests.pl
Lines 2291 to 2294 in 9e560d1
curl/tests/sshserver.pl
Lines 402 to 404 in 9e560d1
I expected the following
My guess is this has something to do with msys2 path interpretation. Maybe the base64 string had a leading / and so msys2 converted that to
C:/msys64/. There is an msys2 environment variable MSYS2_ARG_CONV_EXCL that can be set to stop msys2 from tampering with arguments. That is already done in appveyor configs, for example:curl/appveyor.yml
Line 145 in 9e560d1
I think that should be done for Cirrus CI as well.