Using SSH/SCP From OIE

The OpenGroupware Integration Engine supplies three actions for utilizing the SSH protocol:

• sshGetFileAction - Retrieve a file via SSH copy.
• sshPutFileAction - Upload a file via SSH copy.
• sshExecuteCommandAction - Execute a command on a remote host. Optionally this command can retrieve a file from the remote host if the command completes with an exit status of zero.

All three commands utilize public key authorization, so the a public/private key pair must be available to the OpenGrouwpare server and that public key must be authorized on the remote host.

By default OpenGroupware will attempt to load its private key from the .ssh subfolder of the its user account. For example if OpenGroupware is running as system account ogo and the home directory of user ogo is /var/lib/opengroupware.org the path to folder containing the the key will be assumed to be /var/lib/opengroupware.org/.ssh.

If an alternative path is used to store the key pairs the server default OIESSHPrivateKeyPath must be set to the full path to the private key file (not the path to the folder).

Both RSA and DSA keys are supported. OpenGroupware will prefer the DSA key [assumed to be in the file id_dsa] when attempting to automatically load the keys [if the OIESSHPrivateKeyPath is not specified]. If a DSA key is not found the server will attempt to load the RSA key [assumed to be in the file id_rsa].

$ coils-server-config --directive=OIESSHPrivateKeyPath --value=/home/awilliam/projects/coils-code/root/.ssh/id_dsa
$ coils-server-config --directive=OIESSHPrivateKeyPath
'/home/awilliam/projects/coils-code/root/.ssh/id_dsa'

Text 1: Setting and displaying the OIESSHPrivateKeyPath server default.

The SSH connection opened by OIE always enables keep alive packets at 30 second intervals - but these keepalive packets only serve to maintain the network connection. If when using sshExecuteCommand actions you get disconnected from the remote host due to an idle connection you must address the idle timeout enforced for the session - these types of disconnections are not the result of OIE but an administrative issue of the remote host. If your remote command takes a considerable about of time to complete consider invoking the command in the background [with some equivalent to nohup], parking the workflow process, and having the command executing on remote host post the results of the command back to the process as a message (which will resume the parked process).