The decoded password works and contains a $, so the original suspicion
was right about the upload script even though it was wrong about this
test - typing into a prompt never involved a string literal.
On success the test now prints the line to paste, apostrophes doubled
and single quotes included, and explains why: inside double quotes
PowerShell reads $Pass2026 as a variable and sends a shorter string, so
a correct password still fails. It also flags % for .bat files and
suggests keeping the password in its own file, where no quoting applies.
Checked against a $ password, an embedded apostrophe, a %, and a plain
one that correctly draws no advice at all.
FileZilla works, every copy of its settings fails: the <Pass> value in
an exported sitemanager XML is Base64, not the password. Copied out
verbatim it is rejected by the server every time, which is exactly the
"works in the GUI, fails in a script" shape we have been chasing.
The test can now read the export itself - listing sites by name so the
right practice is picked out of the nine - and decodes the password,
reporting both lengths so the difference is visible. A master-password
protected export (encoding="crypt") cannot be read, and says so.
A typed password that is still Base64 is flagged the same way, since
pasting it by hand is the other route to the same mistake. Guarded
against false positives: it must decode to printable ASCII, so ordinary
passwords are not accused.
Melissa's session log settles the earlier theory: WinSCP negotiated,
sent the password, and srtSSHServer answered "Password authentication
failed". The password was typed into this script rather than read from a
string literal, so PowerShell interpolation was never involved and the
credential is simply not being accepted.
Two changes follow from that. The password is now entered twice and
compared - nothing echoes while typing, so a slipped paste and a good
one look identical, and a test on the wrong string proves nothing.
And the failure report now reads the log rather than dumping matching
lines: it separates "the server rejected the password we sent" from "the
server never offered password auth" from "it failed before any password
was sent", because those three have completely different fixes.
Melissa is going with the script she built with ChatGPT, so the
diagnostic has to stand on its own. It now finds WinSCPnet.dll wherever
it is - a WinSCP folder beside the script, one folder up, a normal
WinSCP install under Program Files, or anywhere below the script - and
asks for the path only if all of that misses.
Unblock-File is registered but throws on Linux, so Get-Command was not a
usable guard for it; wrapped instead.
The ChatGPT transcript showed each CAMBS practice has its own SFTP
account (YSMD is YAM62682 on io.myallylogin.com:14147), not one shared
entity login - so the wizard needed a way to set those without hand-
writing nine practice.json files. Option 5 does that, and the settings
screen now lists which login each practice will actually use.
test-login.bat tests one account on its own, with the details typed in
rather than read from a config, which isolates the account from whatever
a script is doing to the credentials. It reports password length,
stray whitespace, and $ / backtick characters - the last being the usual
reason a login works in the WinSCP window but fails from a script, since
"$pass" interpolates in PowerShell while '$pass' does not. On failure it
prints the authentication methods the server offered.
check.sh runs what has actually caught bugs here: non-ASCII characters,
"$name?" (? is legal in an unbraced variable name, so it renders empty -
this bit twice), parse errors, 5.1 syntax compatibility, and JSON validity.
blance