How To Get Started with the JITL SSH Job

Introduction

This JITL SSH job is used to execute commands, programs and/or shell-scripts on a remote server by SSH.

For more information on SSH see:

http://en.wikipedia.org/wiki/Secure_Shell

SSH is a registered trademark of SSH Communications Security Corp in the United States and in certain other jurisdictions.

SSH Client Implementation

The JobScheduler JITL SSH job uses either an SSH implementation from Trilead or, starting with JobScheduler version 1.9, an implementation of JCraft's JSch.

JSch is the default implementation for the JITL SSH job from JobScheduler version 1.10 onwards and the Trilead SSH implementation will no longer be supported from version 1.12.

The JCraft's JSch implementation allows the features of the JITL SSH job to be extended as described in the How To - Usage of the SSH Job (JobSchedulerSSHJob) with JCraft's JSch article.

This article describes the general usage of the JITL SSH job and should be read before the JCraft JSch article.

Getting Started

The following article describes the basic use of the SSJ job and applies for both use with the Trilead and JSch implementations.

Example for the JobScheduler SSH Job

Additional Features

The additional features made available in the SSH job with the JSch implementation are described in the following article:

How To - Usage of the SSH Job (JobSchedulerSSHJob) with JCraft's JSch

In addition the use of return values and how to switch between the Trilead and JSch implementations are described.

SSH Session Management adds the possibility of ending orphaned remote processes started by SSH jobs or JobScheduler tasks orphaned by SSH jobs. This is described in:

How To - SSH Session Management

The following article describes the parameters available for handling stderr and exit code in the JobSchedulerSSHJob job.

Job JobSchedulerSSHJob - Handling StdErr and ExitCode

Authentication Methods

The following section provides a basic introduction to the authentication methods available for SSH and how they can be implemented with the JITL SSH job.

UserID and Password

This is the easiest way to authenticate a user. The user ID and a password is sent to the SSH server. The password is encrypted before sending it to the server and decrypted at the server side.

Note that the password authentication must be enabled in the SSH configuration file:

/etc/ssh/sshd_config:

PasswordAuthentication yes

Public and private Key

Passphrase: What it is and how to handle it

A passphrase is an additional protection of the key files, like a password. Every time you want to access a server by a passphrase protected key you have to enter the value of the passphrase as an additional authentication.

Note that the publickey authentication must be enabled in the /etc/ssh/sshd_config SSH configuration file:

/etc/ssh/sshd_config:

PublickeyAuthentication yes

In addition, the private SSH-Key must be in OpenSSH-Format.

Creating the public and private key

First we generate the key with ssh-keygen.

kb@wilma:~/.ssh&gt; ssh-keygen -f my-key-set.id_dsa -t rsa

When ssh-keygen askes for a passphrase you can enter your passphrase to add it to the key. Or you can leave it blank. Remember, the longer and stronger you make your password, the harder it will be for any malicious h4x0r (or government agency) to decrypt it. Save the key to /home/username/.ssh/identity as recommended by the ssh-keygen program. You will also need to specify which encryption method (e.g. RSA, DSA) you want to use.

ssh-keygen generates an private OpenSSH key and a public key.

Generating public/private rsa1 key pair.    
Enter file in which to save the key (/home/dave/.ssh/identity): /home/dave/.ssh/identity
Enter passphrase (empty for no passphrase): *enter your passphrase here*
Enter same passphrase again: *repeat your passphrase*
Your identification has been saved in
    /home/dave/.ssh/identity.
Your public key has been saved in 
    /home/dave/.ssh/identity.pub.
The key fingerprint is:
    24:bc:0b:fs:f5:06:1d:c0:05:3a:59:09:e3:07:8a:8d kb@wilma

The private key looks the the key in the lines below:

If puTTYgen is used to create the priv/pub keys it is not an OpenSSH Key by default. To get an OpenSSH conform key you must export the private key to OpenSSH format.

If you want to use the private key in putty as well you have to convert the private key to the openSSH-format. This can be done with puTTYgen as well.

Moving the public key to the remote server

To be able to log in to remote systems using a pair of keys, you first have to add the public key on the remote server to the authorized_keys file in the .ssh/ directory in the home directory on the remote machine.

The Next action is to create a .ssh directory, and inside the .ssh/ directory create an authorized_keys file and add the public key to the file. Make sure the file is not readable for other users/groups. chmod 600 authorized_keys* does the trick.

    [kb@wilma kb]$ mkdir .ssh
    [kb@wilma kb]$ chmod 700 .ssh
    [kb@wilma kb]$ cd .ssh
    [kb@wilma .ssh]$ touch authorized_keys
    [kb@wilma .ssh]$ chmod 600 authorized_keys
    [kb@wilma .ssh]$ cat ../identity.pub &gt;&gt; authorized_keys
    [kb@wilma .ssh]$ rm ../identity.pub

Space shortcuts

Page tree