Password-auth ssh and scp hang in non-interactive shells; ssh2 over Node avoids the TTY

Repro on Windows 11, Node 24, a remote host that accepts password auth only (no key):

1. From Node, spawn `scp` with `child_process.spawn` or `execFile`, stdin and stdout piped, no console attached. 2. Point it at the host: `scp ./file.tgz user@host:/tmp/`. 3. The process waits for a password that nothing can supply. It hangs until your timeout kills it, or it exits with an auth failure.

The same thing happens in any context without a TTY: CI runners, cron or Task Scheduler jobs, and a server process that shells out. The password prompt is not read from stdin. OpenSSH opens the controlling terminal directly (the tty device on POSIX, the console on Windows) and does not use the piped stdin. Piping the password into the process does nothing, because the prompt never reads from that pipe.

The usual workarounds do not carry over to Windows:

- `sshpass` is not available on Windows. - `plink` from PuTTY also needs a console for its prompt. - Keys would solve it, but that is not an option when the host only offers password auth and you do not control its config.

What works is leaving the native CLIs out. `ssh2` is a pure-JS SSH client, and `ssh2-sftp-client` wraps its SFTP subsystem. Neither spawns a process or opens a terminal. The password goes in as a plain string in the connection config, so there is no prompt for anything to hang on.

```js import SftpClient from 'ssh2-sftp-client';

const sftp = new SftpClient(); await sftp.connect({ host: 'example.host', port: 22, username: 'user', password: process.env.SSH_PASSWORD, }); await sftp.put('C:/work/file.tgz', '/tmp/file.tgz'); await sftp.end(); ```

For remote commands rather than transfers, use `ssh2`'s `Client` with `exec`. It gives you stdout, stderr and an exit code as events, which is also easier to handle than parsing a child process's output.

Notes:

- Read the password from an environment variable or a secret store, not from source. - Use forward slashes for the local Windows path, as above. Node accepts them. - Set `readyTimeout` on the connect config so a bad host fails quickly instead of waiting on the default. - Pin or verify the host key with the `hostVerifier` option. Skipping that check removes the protection the native client's known_hosts file gives you.

The takeaway: if a Windows automation path has to use password auth, a library that implements the protocol in-process is more reliable than any wrapper around a CLI that insists on a terminal.