Many people try all different ways, but it seems SSH is implemented so secure that, even if you want to be unsecure a bit, it will not allow you to do so. Many developers and admins go and use expect language to communicate with SSH, create complicated perl and shell script that use really dark corners of your kernel tools (mknod, redirect tmp files, symbolic links manipulation, secret files under /dev, and so on), and doing other dark magic only to enable auto input SSH passwords (in the case, they cannot use authorization keys, of course).
But there exist (relatively) simple solution to this problem. The only thing you need to know is how SSH works, explanation will come later, but first the solution:
First you need to create executable that will spit out the password to stdout: create file ‘./spit_password.sh’ with the contents:
and make it executable:
chmod +x ./spit_password.sh
If it is not executable, ssh will refuse to run it.
Secondly, run following in your shell:
setsid ssh firstname.lastname@example.org
Then ssh will automatically use ‘./spit_password.sh’ output as input for password.
We need to change DISPLAY variable to something wrong, otherwise ssh will refuse accept the password from output of the script.
SSH_ASKPASS tells ssh to use the program to ask password, only if GUI is not available (or DISPLAY variable is wrong), otherwise it will just run GUI program from SSH distribution.
setsid will run the command in the new environment without TTY attached. This is very important, because if ssh sees it is attached to TTY, it will use the standard password input procedure, and not use SSH_ASKPASS.
In short, ssh will try to use all possible ways to escape from using SSH_ASKPASS and ssh will only use SSH_ASKPASS if it cannot use neither GUI nor TTY for asking password, because it has no way to escape from using SSH_ASKPASS (in such a case, SSH_ASKPASS is ssh’s last hope).