Script not reading correct port in profile

I have recently upgraded to 5.14.4 RC - can't remember prior version but it was whatever has recently ceased to be supported.

I run a daily script through Windows Task Scheduler that uses a connection profile stored in the GUI to connect and conduct a simple SFTP transfer.

Connecting through the GUI works fine - it uses port 10023 as it should. However, when the script runs, the logs show it calling the correct profile, but then trying to connect on port 23 and consequently failing.

I have tried editing and re-saving the connection profile in the GUI, but to no avail, the script seems to be ignoring the stored port information in the GUI profile.

Please Help!

Thanks

Paul

Prior version was 5.7.4

Please attach a full session log file showing the problem (using the latest version of WinSCP).


Though in any case, you should not rely on configuration stored in GUI. And it's also quite likely that your script was never using the GUI configuration you are trying to change.
See https://winscp.net/eng/docs/faq_scheduler
Also https://winscp.net/eng/docs/scripting#configuration

Hi Martyn

Please find log file attached with sessions either side of version change. I've highlighted a few differences I could see.

Thanks for your help

Paul

Hi Martin

Just checking this came through?

Sorry, I indeed missed your previous post.

You are a victim of this change:
https://winscp.net/tracker/1647

Your stored site is XMZYTA01@mfttisp.td.com. While your open command uses sftp://XMZYTA01@mfttisp.td.com. Older versions of WinSCP tolerated this discrepancy, while the latest version does not anymore.

Anyway, we advice not to use stored sites in scripting.
https://winscp.net/eng/docs/scripting#configuration

Hi Martin

Thank you for the reply - I have tweaked the script so it calls the configured connection accurately for now and it looks like it is working, but I would like to be using best practice.

When I try using the format suggested in the thread and in the log, there seems to be a problem logging in:

. 2019-03-01 08:56:05.393 Host key matches cached key
. 2019-03-01 08:56:05.393 Initialised AES-256 SDCTR client->server encryption
. 2019-03-01 08:56:05.393 Initialised HMAC-SHA-256 client->server MAC algorithm
. 2019-03-01 08:56:05.393 Initialised AES-256 SDCTR server->client encryption
. 2019-03-01 08:56:05.393 Initialised HMAC-SHA-256 server->client MAC algorithm
! 2019-03-01 08:56:05.443 Using username "(Correct User name)".
. 2019-03-01 08:56:05.480 Server offered these authentication methods: password,publickey,keyboard-interactive
. 2019-03-01 08:56:05.480 Attempting keyboard-interactive authentication
. 2019-03-01 08:56:05.505 Prompt (keyboard interactive, "SSH server: password", "Using keyboard-interactive authentication.
. 2019-03-01 08:56:05.505 Enter password for (Correct User name)", "Password:")
. 2019-03-01 08:56:05.505 Using stored password.
. 2019-03-01 08:56:20.506 Waiting for data timed out, asking user what to do.
. 2019-03-01 08:56:20.515 Asking user:
. 2019-03-01 08:56:20.515 **Host is not communicating for 15 seconds.
. 2019-03-01 08:56:20.515
. 2019-03-01 08:56:20.515 Wait for another 15 seconds?** ()
. 2019-03-01 08:56:37.023 Data has arrived, closing query to user.
. 2019-03-01 08:56:37.023 Received disconnect message (by application)
. 2019-03-01 08:56:37.023 Disconnection message text: Idle connection
. 2019-03-01 08:56:37.023 Server sent disconnect message
. 2019-03-01 08:56:37.023 type 11 (by application):
. 2019-03-01 08:56:37.023 "Idle connection"
. 2019-03-01 08:58:01.744 --------------------------------------------------------------------------

Please attach complete log files both using the URL (failing) and stored site (working).

Attached

NOTE: ACTUAL SCRIPT HAS THE USERNAME INSTEAD OF ***, BUT HAVE ALSO TRIED WITH *** AND GET SAME RESULT

But there should be a password instead of ***, not username. If you have actually meant the "password": Are there any special characters in your password?

Thank you .... I did not realize that I was supposed to put the password where the *** was.

Once I did that (having managed to go back to my archives of several years ago), it all worked fine.

Thanks again for your help

Paul