Puncte:-1

Why PSFTP script is failing when ran as system?

drapel cn

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.

drapel cn
Votez pentru a închide această întrebare deoarece este postată încrucișată la SO: https://stackoverflow.com/questions/70041315/how-to-script-sftp-commands-with-psftp
Puncte:0
drapel cn

Deci, după ce am săpat puțin, se dovedește că PSFTP nu recunoaște cheile serverului ftp. Am deschis cmd ca SISTEM (ceea ce poate fi puțin complicat!) și conectat prin PSFTP, a acceptat să aibă încredere în gazdă (server sFTP), iar apoi scriptul a funcționat conform așteptărilor! Nu a cauzat probleme pentru alți utilizatori, deoarece aceștia au fost utilizați în testare și au primit promptul mai devreme!

FYI cheia este, de asemenea, stocată în Registry sub HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys, deci ar putea fi adăugat acolo pentru alți utilizatori dacă nu doriți să vă autentificați manual (am adăugat această verificare în scriptul meu pentru a o adăuga dacă lipsește pentru orice utilizator care rulează scriptul).

EDIT: Cred că cea mai mare problemă a mea a fost obținerea cmd ca SISTEM astfel încât să pot depana ceea ce se întâmplă, odată ce am putut (vezi linkul de mai sus pentru cum am făcut-o) mi-a devenit clar.Pentru referință și o mai bună claritate, mai jos este rezultatul comenzii înainte de a adăuga cheia, doar mascați părțile sensibile:

C:\Users\myuser>echo ls | psftp -l myftpuser -pw mycomplexpswd sftp_server
Cheia gazdă a serverului nu este stocată în cache. Nu aveți nicio garanție
că serverul este computerul pe care îl crezi.
Amprenta cheii rsa2 a serverului este:
ssh-rsa 2048 SHA256: cheiacomplexfancyhost
Dacă aveți încredere în această gazdă, introduceți „y” pentru a adăuga cheia
Cache-ul PuTTY și continuați conectarea.
Dacă doriți să continuați conectarea o singură dată, fără
adăugând cheia în cache, introduceți „n”.
Dacă nu aveți încredere în această gazdă, apăsați pe Return pentru a abandona
conexiune.
Stocați cheia în cache? (da/nu, Return anulează conexiunea, pentru mai multe informații) 
Folosind numele de utilizator „myftpuser”.
Mesaj banner de pre-autentificare de la server:
| Conectare FTP companie - Vă rugăm să introduceți acreditări valide pentru a continua
Sfârșitul mesajului banner de pe server
Solicitări de autentificare interactivă de la tastatură de la server:
Sfârșitul solicitărilor interactive de la tastatură de la server
Directorul de lucru la distanță este /
psftp> ieși
drapel so
Dar nu puteți obține *"Directorul de lucru la distanță este /"* dacă aceasta a fost problema. Deci nu ne-ați dat informațiile corecte.
amyassin avatar
drapel cn
@MartinPrikryl Înțeleg de ce presupui asta, dar asta am primit. Am incercat si pe alt server si am obtinut aceleasi rezultate! nu e ceea ce ma asteptam si eu..Eroarea nu a fost introdusă în fișier doar acele linii..
drapel so
Nu veți primi *„Cheia gazdă a serverului nu este stocată în cache”* în `ls.txt`, deoarece redirecționați numai stdout, nu stderr. Asta e de așteptat. â Dar nici nu puteți obține *"Directorul de lucru la distanță este /"*, deoarece puteți obține asta numai după ce vă conectați efectiv, ceea ce nu ați făcut.
amyassin avatar
drapel cn
@MartinPrikryl Da, înțeleg și sunt total de acord cu tine, dar asta s-a întâmplat. Crezi ceva care ar putea merge prost sau diferit? Nu am dat informații greșite, doar ce am primit..
drapel so
nu inteleg comentariul tau. + Btw, o soluție mai bună pentru acceptarea cheii gazdă este utilizarea comutatorului `-hostkey`.
amyassin avatar
drapel cn
@MartinPrikryl Am șters cheia din Registry și am încercat din nou din cmd și mi-am editat răspunsul, astfel încât să puteți vedea rezultatul pe care îl obțineam. Cea mai mare parte este în stderr cred, dar are rezultatul `Directorul de lucru la distanță este /`.
amyassin avatar
drapel cn
De asemenea, mulțumesc pentru sfatul `-hostkey`, cred că este mai bine...
drapel so
Ok, deci *te-ai conectat*, deoarece `ls` a fost luat ca o confirmare a promptului (ca `n`). Și deoarece nu mai existau comenzi în intrare, nu s-a făcut nimic altceva. Ok, scuze atunci. (Dimpotrivă, cu `-b` nu vă veți conecta, deoarece nu există niciun răspuns la prompt).
drapel so
Deci asta înseamnă că cu `-b` nu veți obține *"Directorul de lucru la distanță este /"*, este corect? Contrar a ceea ce spune întrebarea ta de pe SO.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.