Your shell can only redirect its own file descriptors. It can't stop any program from opening new ones.

Security-wise, unencrypted passwords are grade-A dangerous. They shouldn't ever get stored in any retrievable form, and should go directly from actual humans to system logins in as few vulnerable steps as possible.

The obvious way to tell a human apart from an intermediate program is that humans will always be found using terminals... ssh, and indeed most login systems(su, sudo), demand that an actual terminal be used to enter passwords. Pipes, files, and sockets won't do.

There's another property a process has beyond stdin/stdout/stderr, the controlling terminal. If there's a terminal in charge of a process, there's probably a logged-in human behind it that's using that terminal. They can be contacted directly via opening /dev/tty regardless of whether a program inherited any references to that terminal or not.

So, to guarantee that they're getting passwords from a human and not an automated password cracker or an in-between password recorder, and talking to a human and not a script -- and to let su - work even if it's crammed in the middle of a pipe chain! -- these things go directly to the terminal in charge of the process and accept nothing less.

/dev/tty knows what your terminal is without any effort on your part. Open it and it acts like you opened your proper terminal, which might be /dev/pts/3, or /dev/tty1, or any of a lot of possibilities. No. It uses a system call to see whether what it's opened is actually a terminal. You'd probably mess up some important things by playing with device files like that anyway.

The solution is to open your own virtual terminal, and use that to control your program. It's as good as any other terminal as far as ssh's concerned. The expect language does this. Otherwise this'd mean some C coding.