We have a TCP/UPD service defined for WinSCP. The client application string is
<WinSCP.exe Path> sftp://<User>:<Password>@<Local IP>:<First Port> /sessionname=<Device Name>
When the service is launched from the PAM access page it normally successfully connects to the target device with the credentials defined in the access policy. But sometimes it doesn't work for connections to specific hosts. It's not always the same hosts. At one time connections to host A may fail, but not host B, and at other times connections to host B fail, but not host A.
When the problem is observed we see WinSCP trying to connect to a host with a name that matches the target account name, and then reports error "Host <user> does not exist".
This affects any currently supported PAM release as of September 2019.
It was found that the problem occurs whenever the target account password included the forward slash character "/". PAM does not escape special characters when replacing the <User> and <Password> tokens with target account name and password. This can cause a problem for WinSCP, see e.g. https://winscp.net/eng/docs/session_url
For PAM releases prior to 3.4.3 remove problem special characters from the Password Composition Policies (PCPs) for the target accounts that may be used with WinSCP. Out of the default set of special characters for PAM PCPs the forward slash character was identified as causing a problem. Other special characters did not appear to cause a problem.
A better solution would be to not use the <Password> token in the TCP/UDP service definition at all. If you configure a target account for auto-login in an access policy for this service, the PAM SSH proxy should be able to automatically insert the password at the right time, w/o exposing the password to the WinSCP application and thus to the PAM user. Support of SFTP auto-login by the SSH proxy was added in the 3.4.3 release, see here.
A Client Application string like the following should work with PAM releases 3.4.3 and newer:
"C:\Program Files (x86)\WinSCP\WinSCP.exe" sftp://<User>@<Local IP>:<First Port> /sessionname=<Device Name>
If you enable WinSCP logging at debug level 1, it will show the full connection string in the log if the password field is not read properly due to a problem character. This should allow you to identify any other character that causes this problem, if you run into it. Note that in this case the password will be shown in plain text in the WinSCP log file.