Concept and mechanism
Reliable automation requires preparing authentication and trust before starting the job. BatchMode=yes avoids interactive questions but supplies neither credentials nor independent confirmation of an unknown key. The scheduler account can have configuration, local directory, and key access different from the operator account. Compare contexts and effective configuration without indiscriminately copying personal files. Also distinguish both transfer sides: cd changes the remote directory while lcd handles the local one. A put using a relative path can select the wrong file if the job starts elsewhere. Explicit paths and a known identity reduce these operational ambiguities.
Guided application
In OpenSSH batch mode, failures of critical operations such as put and rename normally abort the sequence. A prefix suppressing termination needs a specific justification. Do not publish a file as ready after ignoring upload failure. The wrapper should propagate the relevant outcome to the scheduler; a final success message does not change what happened during transfer. In a fictional exercise, the job turns green despite a logged error and starts the consumer. Correct both the advancement condition and returned status. Retain identifiers and enough error detail for recovery, distinguishing failure, confirmed delivery, and an uncertain outcome.
put fails: partial content must not be published or a dependency advanced as though delivery succeeded.
Common pitfalls
BatchMode as a credential; manual account as scheduled account; logging as control; last command as delivery.
Related topics: Transport and server trust · Permissions and isolation · File publication and resumption
Make delivery a verifiable condition of flow and job status.
Reference: OpenSSH SFTP client · DR SFTP 2026-09; selected OpenSSH client, server and extension behavior