DATE: 06/02/2004

Several ways to establish an ssh-connection
_____________________________________________

SSH Protocol 1:

1) A file that lists which users are permitted to log in from which machines (/etc/hosts.equiv). Very unsafe and not recommendable.
2) Authentification via a pair of keys (one public key that is known to the remote machine and one private key which is only known
   to the local host). The user's public key must be stored in the file $HOME/.ssh/authorized_keys on the remote machine. This method
   allows a login without providing a password.
3) Normal password method. Not really an option in our case since we'd have to put the password into the script file. In cleartext, too!

SSH Protocol 2:

Very much like protocol 1.


Method 2) is definitely the way to go IMO. It's secure, simple and does not require us to put any password information in our script. 
The problem is, if any user should be able to run the testsuite then all of those users must have their publics key stored in their home 
directories on all of the executing hosts and their private keys must be present on the issuing host.
I figure we may circumvent this problem by creating a new user specifically for the purpose of running the testsuite and then having the
program assume the identity of that user when it's being run. Alas this throws up another problem, that being that setting the SUID bit for
a script is somewhat unsafe since other users might just alter the script to abuse the permissions inherent to our 'artificial' user that we created for the purpose of running the script. This could be remedied by making the script non-writable to all other users (the only folks who
need to be able to write to the script are the developers really).

Useful options to supply to ssh
__________________________________

-2 => Use SSH protocol 2
-f => Cause ssh to go to background before  command execution.
-i => Specify and identity file (file in whhich the private key is stored).
-n => Redirect STDIN from /dev/null
-q => Quiet mode. Suppress diagnostic and wwarning messages.
-v => Debug output. Can be specified up to  3 times for increased verbosity.

DATE: 06/03/2004

example: ssh -2 -f -i ~/.ssh/id_rsa -n -q kiew perl ~/Project/testsuite.pl -make . ~/Project/dTestdir -verbose

The problem with remote execution via ssh is that even if the executed command is run in the background, the ssh connection will still remain open until the command has finished. To work around this we could write a little script start.pl that does nothing more than fork() a new process to run the actual command and exits immediatedly thereafter. Thus to fire up the testsuite, we'd merely run ssh <remote_host> perl start.pl. AH ... nope, that won't work either. By forking, we are giving the child process the exact same file handles (including stdin and stdout) that the parent process uses. Therefore, the output of the child process will also go to the issuing host. =( Grrr ... 

DATE: 06/16/2004

The solution is to daemonize the spawned work process, which effectively detaches it from the ssh-tty, meaning the ssh program can safely exit and the started program will still continue tor run just fine. That seems to work fine so far, and I'm not getting any zombie processes either.

DATE: 06/25/2004

Actually we needn't use the -f option at all, as our daemonize() function does all necessary things to detach the executed command from the
ssh already. 

DATE: 06/27/2004

Right, it seems we can use ssh without any of the fancy options listed above. A simple ssh call will do. We're going to log in on the 
remote machine and start a program, which in turn fires up a daemonized instance of our testsuite program on that machine. The 
ssh-connection merely remains open for the time it takes to start the former program (which experience has shown to be around 4 to 
5 seconds per host).
