The ssh client is specifically programmed to not accept passwords from standard input: it explicitly reads the terminal device, bypassing any input/output redirection. The "passwd" command does the same.
This is done intentionally to discourage users from writing scripts with embedded passwords. Accepting the password from an environment variable is not implemented, for the exact same reason.
This mechanism is not perfect: it can be bypassed with a bit of effort, but it is intended to make the user think about finding a better (hopefully more secure) way to solve his/her access or automation problem.
With password authentication, an unauthorized person needs only to read the script once, and then s/he can make unauthorized connections from any location that otherwise allows connections to the target system.
With SSH keys, you can place restrictions on keys at the server side, so that a particular key is accepted only if the connection comes from an IP address that is specifically listed as trusted for that key.
It is even possible to allow/force a certain key to always run one particular command only, so that even if the private key has been compromised, the server admin knows that the worst thing the intruder can do with the key is to keep doing what the legitimate user normally does.
For more information, type "man sshd" on your system and read the chapter titled "AUTHORIZED_KEYS FILE FORMAT".
Of course the SSH keys can be misused, just like anything else. But with SSH keys, at least you have a tool that allows you to achieve markedly better security with just a little bit of extra effort.
If your system is subject to security audits, you should always document your embedded passwords and other well-known security risks in advance. You should also document the technical reasons why the known-risky solution was chosen: "I did not want to use SSH keys" is not going to be an acceptable justification.
MK
MK
