Context: I have CSV files I'm outputting from SQL Server through BCP. I'm trying to securely transfer the files to a remote SFTP folder using WinSCP.
Details: When I execute the batch file below through powershell I raise an error 'Unknown command 'ssh-rsa' with the log file showing an exit code = 1 which is failure.
Here is what my synchronization file looks like...
option batch abort
option confirm off
open sftp://username:password@sftp.redacted.com -hostkey="ssh-rsa 2048 redacted=ssh-rsa 2048 redacted"
synchronize remote D:\redactedDaily_Reports\redacted_Catalog_New_Item /upload/redacted_catalog
exit
and & my batch file...
winscp.com /script=SyncTo_redacted_catalog.txt /log=D:\redacted_Daily_Reports\winscp_log_catalog.txt
pause
Here is a snippet of my powershell output and log file... powershell output
. 2019-03-06 23:39:28.379 Access granted
. 2019-03-06 23:39:28.379 Opening session as main channel
. 2019-03-06 23:39:28.447 Opened main channel
. 2019-03-06 23:39:28.583 Started a shell/command
. 2019-03-06 23:39:28.583 --------------------------------------------------------------------------
. 2019-03-06 23:39:28.584 Using SFTP protocol.
. 2019-03-06 23:39:28.584 Doing startup conversation with host.
> 2019-03-06 23:39:28.584 Type: SSH_FXP_INIT, Size: 5, Number: -1
< 2019-03-06 23:39:28.769 Type: SSH_FXP_VERSION, Size: 95, Number: -1
. 2019-03-06 23:39:28.769 SFTP version 3 negotiated.
. 2019-03-06 23:39:28.769 Unknown server extension posix-rename@openssh.com="1"
. 2019-03-06 23:39:28.769 Supports statvfs@openssh.com extension version "2"
. 2019-03-06 23:39:28.769 Unknown server extension fstatvfs@openssh.com="2"
. 2019-03-06 23:39:28.769 We believe the server has signed timestamps bug
. 2019-03-06 23:39:28.769 We will use UTF-8 strings until server sends an invalid UTF-8 string as with SFTP version 3 and older UTF-8 strings are not mandatory
. 2019-03-06 23:39:28.769 Limiting packet size to OpenSSH sftp-server limit of 262148 bytes
. 2019-03-06 23:39:28.769 Getting current directory name.
. 2019-03-06 23:39:28.769 Getting real path for '.'
> 2019-03-06 23:39:28.769 Type: SSH_FXP_REALPATH, Size: 10, Number: 16
< 2019-03-06 23:39:28.837 Type: SSH_FXP_NAME, Size: 23, Number: 16
. 2019-03-06 23:39:28.837 Real path is '/'
. 2019-03-06 23:39:28.837 Startup conversation with host finished.
< 2019-03-06 23:39:28.837 Script: Active session: [1] redacted@sftp.redacted.com
> 2019-03-06 23:39:28.838 Script: ssh-rsa 2048 redacted
< 2019-03-06 23:39:28.838 Script: Unknown command 'ssh-rsa'.
. 2019-03-06 23:39:28.838 Script: Failed
. 2019-03-06 23:39:28.838 Script: Exit code: 1
. 2019-03-06 23:39:28.838 Closing connection.
. 2019-03-06 23:39:28.838 Sending special code: 12
. 2019-03-06 23:39:28.838 Sent EOF message
Questions: Why am I raising this error & how do I fix it? Is this error trying to tell me that I'm using an incorrect key-fingerprint -- If so, why is that the case when a) I obtained this key directly from the server when I connected successfully the first time and b) the log file appears to show the initial connection was successful?
Please help Any tips or recommendations greatly appreciated -- responses will probably reach a decent sized audience given that winscp is a pretty popular utility. I've done my research here, here, here, here, here, here and here & haven't found a suitable solution.
This is nonsense:
-hostkey="ssh-rsa 2048 redacted=ssh-rsa 2048 redacted"
(where have you seen such a strange syntax?)
It should be like:
-hostkey="ssh-rsa 2048 xxxxxxxxxxx...="
Though it does not really explain the error message you are getting – unless there are some special characters (like double quotes) in the redacted part.
In general, the easiest way is to have WinSCP GUI generate correct script template for you.
Or, if you want to go a manual way, see:
Where do I get SSH host key fingerprint to authorize the server?
Particularly the section "Automatic host key verification" (though you will want to read the article from the beginning).
I'm aware that you refer to this article yourself. But then I do not understand how you could have arrived to your strange syntax.