Introduction

The JS7 - JITL SSHJob implements an SSH client (Secure Shell) and allows execution of shell code, scripts and programs on a remote host without a JS7 Agent being installed on that host. As a prerequisite the remote host has to operate an SSH server. The JITL SSHJob is used as an alternative to the ssh Command Line Client, it exceeds the capabilities of ssh in a number of ways.

Agentless Scheduling is not a replacement for use of JS7 Agents.

When to use SSH

  • In a situation in which no JS7 Agent is available for the target platform, for example on mainframe platforms.
  • In an on-premises environment with relaxed security requirements for which full access between two systems is acceptable.
  • In a scenario that does not require high availability and clustering but is limited to remote execution on an individual machine.

When not to use SSH

  • When using job scheduling in a Cloud Environment: SSH is not a suitable method for interaction between containers. Cloud architectures are based on services offered by containers. SSH is a way to break into your neighbor's door instead of asking a service. SSH is not a cloud compatible approach.
  • Security-wise SSH is a risk as it implements Code Injection on a remote system. SSH offers to impersonate any preconfigured account and to execute arbitrary code. The problem with impersonation is that there are no limits to what an account can execute on a remote system. SSH cannot be controlled in a reasonable way to limit an account's capabilities - and otherwise ends in a nightmare such as sudo configurations that introduce more insecurity the more complex they become.
  • When High Availability is required: SSH does not include clustering capabilities as it works for a single machine only. JS7 offers the JS7 - Agent Cluster for redundancy and scalability of job execution with remote systems.
  • When Reliable Termination of Jobs is required: the SSH architecture operating a client on the local machine and a daemon on the SSH server that starts the effective processes for a job does not allow reliable termination. Modern SSH servers can kill a running process if the connection from the client is lost. This might not work in case of connections being dropped by a firewall triggering for idle timeouts if jobs are running for a longer time. And this does not apply to detached child processes. A JS7 Agent can reliably terminate jobs and any processes started from such jobs.

Feature Summary

Remote Job Execution

The SSHJob allows execution on Unix and Windows systems.

  • The beauty of SSH is its simplicity. It allows public/private key authentication and is well suited to execute programs for specific accounts.
    • The JITL SSHJob allows shell scripts to add return values to orders.
  • One of the restrictions of SSH connections is that there is limited control of child processes on the remote host. 
    • If a number of child processes are spawned by a program during an SSH session and that session is aborted then child processes will continue to run.
    • The SSHJob provides a method for monitoring SSH connections that allows both remote sessions and local task to be terminated.

Remote Host Connections

  • The SSHJob connects to a remote host without the need to install a local SSH client.

  • Supported operations on the remote host include:
    • executing commands (including commands that are specific for the operating system),
    • executing scripts,
    • transferring scripts to the remote host and to execute such scripts on the remote host,
    • propagating environment variables to the remote host,
    • adding return values to orders for use with follow-on jobs in the workflow.

Session Management

  • Provides control over remote sessions.
  • Rules the termination of remote child processes and parent processes on Unix systems using SIGTERM and SIGKILL signals.

Drawbacks

Further Resources