Есть ли способ разумно сделать это:

scp user@host:/path/to/file /dev/tty | openssl [options] | less

без создания файла и без необходимости указывать пароль непосредственно в аргументах?

Проблема в том, что оба процесса запрашивают пароль, но порядок их запуска (и, следовательно, порядок, в котором они запрашивают пароль) неопределен.

Было бы нормально сначала завершить scp, а затем запустить openssl, но без временного файла.

Возможные решения на данный момент

• положить вывод scp в переменную, а затем из переменной в openssl (это будет осуществимо только для небольших файлов, и я подозреваю, что могут возникнуть проблемы с бинарными данными и т.д.)
• положить пароли в файлы (не лучший вариант)
• использовать ключи (лучше?)
• использовать именованные каналы

Версия именованных каналов 1

mkfifo pipe && {
  scp user@host:/path/to/file pipe    # запрашивает пароль, затем ждет
                                      # завершения чтения из канала,
                                      # что произойдет только после того,
                                      # как был введен пароль для openssl
                                      # => нужно ^Z и ввести пароль
                                      #  => `pipe: Interrupted system call'

  openssl [options] -in pipe | less
}

Версия именованных каналов 2

mkfifo pipe && {
  scp user@host:/path/to/file pipe &  # запрашивает пароль (и работает, когда
                                      # введен пароль) несмотря на то, что
                                      # помещен в фоновый режим (что? как?
                                      # может кто-то объяснить?)

  openssl [options] -in pipe | less   # `bad password read'
}

Версия именованных каналов 3

mkfifo pipe && {
  scp user@host:/path/to/file pipe |  # сначала запрашивает пароль

  openssl [options] -in pipe | less   # запрашивает пароль после того, как
                                      # был введен пароль от scp
                                      # и все работает нормально
}

Поменять команды местами не помогает.

openssl [options] -in <(scp user@host:/path/to/file /dev/tty) | less не работает.

Может кто-то

1. предложить другое решение,

2. объяснить необычное поведение scp в примере 1 (`Interrupted system call’) (я предполагаю, что это либо ошибка, либо некое “защитное свойство”),

3. объяснить, как работает ввод паролей, например, как задача, которая была запущена в фоновом режиме, может читать из stdin,

4. (связано с 3.) объяснить, почему scp в примере 2 выводит запрос пароля, даже если stdout и stderr перенаправлены в /dev/null ?

scp user@host:/path/to/file /dev/tty пытается отправить содержимое удаленного файла в tty, а не в канал для openssl.

Насколько мне известно, ssh/scp не позволяют считывать пароли из stdin, вы можете использовать sshpass, если не можете воспользоваться более безопасными способами аутентификации. scp предназначен для копирования файлов, а не для вывода их содержимого. Вы можете использовать ssh cat вместо этого или даже сжимать данные на лету, чтобы сэкономить трафик.

И sshpass, и openssl поддерживают ввод паролей из переменных окружения.

SSHPASS=$password_for_ssh sshpass -e ssh host 'gzip -3 < /path/to/file' |
  gunzip |
  PASS=$password_for_openssl openssl -passin env:PASS ...