Score:-1

Why PSFTP script is failing when ran as system?

cn flag

I have a Windows cmd batch file that should retrieve listing of files that are on an FTP server via sFTP using PuTTY PSFTP exe and use that for further processing. The cmd is:

echo ls | psftp -l myusername -pw mycomplexpwd FTPServerHostname > C:/Users/myuser/Desktop/ls.txt

It is supposed to output the listing in ls.txt file that I use in other scripts. When running as a normal user, I get the listing alright. However, when using Task Scheduler and schedule the script as SYSTEM user, I get only this in the output file:

Remote working directory is /
psftp> quit

I guessed that there is a problem in the pipe | usage or something so I also tried using this syntax but also same output:

psftp -l myusername -pw mycomplexpwd FTPServerHostname < C:/Users/myuser/Desktop/lscmd.txt > C:/Users/myuser/Desktop/ls.txt

What could be causing the problem when scheduling the job as SYSTEM instead of my user? And how to get the listing as SYSTEM? Note that when running the script as Administrator (right click - Run as Administrator) I get the listing alright, the problem is only when using task scheduler and schedule the task as SYSTEM.

OS is Windows Server 2012 R2.

cn flag
I’m voting to close this question because it's crossposted to SO: https://stackoverflow.com/questions/70041315/how-to-script-sftp-commands-with-psftp
Score:0
cn flag

So, after digging a bit, turns out that PSFTP doesn't recognize the keys to the ftp server. I opened cmd as SYSTEM (which can be a bit tricky!) and connected via PSFTP, accepted trusting the host (sFTP server), and afterwards the script worked as expected! It didn't cause problems for other users as they were used in testing and had the prompt earlier!

FYI the key is also stored in Registry under HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys, so it could be added there for other users if you don't want to login manually (I added that check in my script to add it if missing for any user running the script)..

EDIT: I believe my biggest problem was getting cmd as SYSTEM so I can debug what is happening, once I could (see link above for how I did it) it became clear to me. For reference and better clarity, below is the output of the command before adding the key, just masked the sensitive parts:

C:\Users\myuser>echo ls | psftp -l myftpuser -pw mycomplexpswd sftp_server
The server's host key is not cached. You have no guarantee
that the server is the computer you think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 SHA256: thecomplexfancyhostkey
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n, Return cancels connection, i for more info) 
Using username "myftpuser".
Pre-authentication banner message from server:
| Company FTP Login - Please enter valid credentials to continue
End of banner message from server
Keyboard-interactive authentication prompts from server:
End of keyboard-interactive prompts from server
Remote working directory is /
psftp> quit
so flag
But you cannot get *"Remote working directory is /"* if this was the problem. So you didn't give us the correct information.
amyassin avatar
cn flag
@MartinPrikryl I understand why you assume that but that is what I got. I tried it in another server as well and got the same results! Not what I expected as well.. The error was not piped into the file only those lines..
so flag
You won't get the *"The server's host key is not cached"* to the `ls.txt`, as you are redirecting stdout only, not stderr. That's expected. – But you cannot get *"Remote working directory is /"* either, as you can get that only after you actually connect, what you did not.
amyassin avatar
cn flag
@MartinPrikryl Yes I understand, and I agree with you totally, but that what happened. Anything that might went wrong or different you think? I have not given wrong information, just what I got..
so flag
I do not understand your comment. + Btw, better solution for accepting the host key is using `-hostkey` switch.
amyassin avatar
cn flag
@MartinPrikryl I deleted the key from Registry and retried from cmd again, and edited my answer so you can see the output I was getting. Most of it is in stderr I believe, but it has output of `Remote working directory is /`.
amyassin avatar
cn flag
Also, thanks for the `-hostkey` tip, that is better I believe..
so flag
Ok, so you *did connect*, because the `ls` was taken as a confirmation of the the prompt (as `n`). And as there were no further commands in the input, nothing else was done. Ok, sorry then. (On the contrary with `-b` you won't connect, as there's no response to the prompt).
so flag
So that means that with `-b` you won't get the *"Remote working directory is /"*, is that correct? Contrary to what your question on SO says.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.