When using scp|ssh in nohup|cron|batch in a non interactive mode, sshconnect1.c and sshconnect2.c do not have the ability to call read_passphrase in such a manner to cause ssh-askpass to be utilized as documented in the man pages. The calls are as follows for the released code: # grep 'read_passphrase(' sshconnect[12].c-original sshconnect1.c-original: passphrase = read_passphrase(buf, 0); sshconnect1.c-original: response = read_passphrase(prompt, 0); sshconnect1.c-original: password = read_passphrase(prompt, 0); sshconnect2.c-original: password = read_passphrase(prompt, 0); sshconnect2.c-original: passphrase = read_passphrase(prompt, 0); sshconnect2.c-original: response = read_passphrase(prompt, echo ? RP_ECHO : 0); (white space adjusted above) Note that the second arguments are all set to zero. To make ssh work as documented one call in each of the two sshconnect[12].c source files must be altered to have the enabling second argument as below: # grep 'read_passphrase(' sshconnect[12].c sshconnect1.c: passphrase = read_passphrase(buf, RP_ALLOW_STDIN); sshconnect1.c: response = read_passphrase(prompt, 0); sshconnect1.c: password = read_passphrase(prompt, 0); sshconnect2.c: password = read_passphrase(prompt, 0); sshconnect2.c: passphrase = read_passphrase(prompt, RP_ALLOW_STDIN); sshconnect2.c: response = read_passphrase(prompt, echo ? RP_ECHO : 0); With this one single change to each of the sshconnect[12].c source files, ssh will work as documented. Note the RP_ALLOW_STDIN constant. This has been tested with protocols 1 and 2. Note how the call is structured with ssh-add.c # grep 'read_passphrase(' ssh-add.c pass = read_passphrase(msg, RP_ALLOW_STDIN); (I am using a self-decrypting binary* for ssh-askpass which authenticates the calling self-decrypting binary* which calls scp and ssh. This authentification is done via a number of environmental variables. After scp completes, these authentificating environmetal variables are immediately unset. So this is quite secure and ssh-askpass will not yield the passphrase to any non autheticated invoking process. The use of ssh-agent and ssh-add are quite unsuitable for my requirements, and would otherwise not be secure. These measures may seem excessive but are neccesary to overcome the security risks involved in more basic cron'd ssh-askpass implementations. I do-not/can-not assume a trust relationship with root on the any systems where my applications are run.) * - these two self-decrypting binaries can be the same binary - FreeEss is being used to create the self decrypting binaries
The suggested change is incorrect. ssh may have stdin redirected from something else - you do not want to read the passphease from there (e.g. the output of a pipe). BTW the passphrase reading does work as advertised, it states: > If ssh needs a passphrase, it will read the passphrase from the > current terminal if it was run from a terminal. If ssh does not > have a terminal associated with it but DISPLAY and SSH_ASKPASS > are set, it will execute the program specified by SSH_ASKPASS > ... just because you have redirected stdin does not mean you have lost your controlling terminal. You need to call setsid to do that. You may be interested in the patch on Bug #69 though
D. Millers commnents are interesting. However it seems that they changes that I suggest are required to run scp in a nohup'd script, with no executables other that ssh and scp. The use of setsid would seem to not apply if one is using shell scripting and shell commands. The code change I suggest makes things work and it fails to use ssh-askpass without. So why is allow stdin used for ssh-add if is so dangerous. My understanding of the code, which is very limited, is that this variable allows the passphrase stdin to come from the stdout of sss-askpass.
If you allow from stdin then something like: nohup sh -c "tar cvf - /home/blah | ssh foo 'gzip -9 > /home/backup/foo2'" will attempt to read the passphrase from the output of the tar command. If you wish to discuss this behaviour further, please use the mailing list and do not reopen the bug.
Mass change of RESOLVED bugs to CLOSED