two piped commands, each needs to read password from stdin

Is there a way to sensibly do this: scp user@host:/path/to/file /dev/tty | openssl [options] | less without creating a file, and without having to supply either password directly in arguments? The problem is, that both ask for password, but the order in which they start (and therefore also the order in which they ask for the password) is undefined. It would be OK to first finish scp and then start openssl, but without a temporary file.

#**Possible solutions so far** - put the output of scp into variable and then from variable into openssl (would be feasible only for small files, plus I suspect there might be some problems with binary data, etc.) - put passwords in files (_not good_) - use keys (_better?_) - use named pipes
**Named pipes version 1** mkfifo pipe && { scp user@host:/path/to/file pipe # asks for password, then waits # for read from pipe to finish # which will only happen after the # password for openssl was supplied # => must ^Z and enter the password # => `pipe: Interrupted system call' openssl [options] -in pipe | less }
**Named pipes version 2** mkfifo pipe && { scp user@host:/path/to/file pipe & # asks for password (and works when # password is entered) despite being # put in background (what? how? # can someone explain?) openssl [options] -in pipe | less # `bad password read' }
**Named pipes version 3** mkfifo pipe && { scp user@host:/path/to/file pipe | # asks for password first openssl [options] -in pipe | less # asks for password after scp's # password has been entered # and everything works fine } Switching the commands around doesn't help.
`openssl [options] -in Could someone
1. propose another solution, 2. explain scp's unusual behavior regarding example 1 (`Interrupted system call') (I'm asuming it's either a bug or something of a "security feature"), 3. explain how entering passwords works, eg. how a task, which was started in background, can read from stdin, 4. (related to 3.) explain why does scp in example 2 print the password prompt even if stdout and stderr are both redirecred to /dev/null ?