Is there a way to sensibly do this:scp user@host:/path/to/file /dev/tty | openssl [options] | lesswithout 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 farput 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 pipesNamed pipes version 1mkfifo 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 2mkfifo 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 3mkfifo 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 <(scp user@host:/path/to/file /dev/tty) | less doesn't work.Could someone propose another solution,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),explain how entering passwords works, eg. how a task, which was started in background, can read from stdin,(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 ?
two piped commands, each needs to read password from stdin
command line;pipe;scp;openssl;fifo