Re: SFTP Connection Requiring Password to Open SSH Keyring File on Remote Server from PS/.Net script
I discovered the problem is related to the folder path to the keyring defined using a mapped drive letter (user ID and password credentials required) versus using a UNC path (no credentials required). This assumes I am running the script under a user credential that already has appropriate access permission to the UNC path on the remote server.
I want to note the script code I used came directly from the WinSCP UI .Net Assembly script generation tool. By default, the generated script created folder paths Session variable values (re: SshPrivateKeyPath) with a drive letter, not a UNC path.
There could be some Windows security policy changes made to allow remote connections using drive letters instead of UNC path without requiring a user ID and password, but from what I've read, it sounds like altering (re: loosening) security policies is not best practice for a number of reasons.
There may be an enhancement opportunity here for WinSCP to generate a folder path with the UNC naming convention instead of drive letter, or give the user the option to select the path name convention when generating the script.
I consider this issue resolved, but I will leave this post up in case someone else encounters the same issue.
I want to note the script code I used came directly from the WinSCP UI .Net Assembly script generation tool. By default, the generated script created folder paths Session variable values (re: SshPrivateKeyPath) with a drive letter, not a UNC path.
There could be some Windows security policy changes made to allow remote connections using drive letters instead of UNC path without requiring a user ID and password, but from what I've read, it sounds like altering (re: loosening) security policies is not best practice for a number of reasons.
There may be an enhancement opportunity here for WinSCP to generate a folder path with the UNC naming convention instead of drive letter, or give the user the option to select the path name convention when generating the script.
I consider this issue resolved, but I will leave this post up in case someone else encounters the same issue.