I have successfully created a syntax that uses the WinSCPnet.dll (.NET assembly). Also, a config.xml file has been created to provide the credentials and start the session. I do this successfully with everything except the password!
Here is the script that works:
[xml]$Config = Get-Content "*\Config.xml"
# Load WinSCP .NET assembly
Add-Type -Path "C:\Program Files (x86)\WinSCP\WinSCPnet.dll"
# Set up session options
$sessionOptions = New-Object WinSCP.SessionOptions -Property @{
Protocol = [WinSCP.Protocol]::Sftp
HostName = $Config.Configuration.HostIP
UserName = $Config.Configuration.UserName
Password = "Actual Password"
PrivateKeyPassphrase = $Config.Configuration.PassPhrase
SshHostKeyFingerprint = $Config.Configuration.FingerPrint
SshPrivateKeyPath = $Config.Configuration.SshPrivateKeyPath
}
I cannot get it to work by replacing the "Actual Password" with $Config.Configuration.Password. I can get the object $Config.Configuration.Password to output the correct password when I run it on it's own. Within the xml file, I have accounted for escape characters. Does anyone know of other reasons why this would not work?
The error message:
Exception calling "Open" with "1" argument(s): "Connection has been unexpectedly closed. Server sent command exit status 0.
Authentication log (see session log for details):
Using username "Actual Username".
Authenticating with public key "imported-openssh-key" from agent.
Further authentication required
Access denied.
Authentication failed."
At *\PS_winSCP.ps1:25 char:5
+ $session.Open($sessionOptions)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : SessionRemoteException
Any help would be greatly appreciated! Thank you
I am going to try to provide the main idea without giving too many details about the password.
The "Actual Password" was the password I imputed directly into PowerShell in order for the session to open. This does not necessarily match the TRUE password of the server. PowerShell cannot use the TRUE password because it has some special characters of it's own.
So when the "Actual Password" (Not the TRUE password) was imputed into the xml file, it was read correctly into PowerShell, but was the incorrect password. So it took me a while to figure out that the xml file did not have the exact TRUE password.
Long story short; try make sure the password in the xml file is exactly correct.