Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

Introduction

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

The current article is intended to function as a guide through the articles we have about SSH and to provide some basic information about authentication methods available for SSH.

For more information on SSH see:

...

All  related programs in JobScheduler are using an implementation of Trilead on the client site. This requires to take some things into account.

Trilead requires a SSH protocol with at least version 3. All other versions are not supported.

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

Different Methods to authenticate

UserID and Password

This is the easiest and most popular method to authenticate a user. The userid and a password is send to the SSH server. Best of all, the password is encrypted, before sending it to the server and decrypted at the server side. but, at the end, it is a password and if someone is able to decrypt he has opened the door to the server.

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 SSH configuration file /etc/ssh/sshd_config:

PasswordAuthentication yes

First of all, 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> ssh-keygen -f my-key-set.id_dsa -t rsa

When ssh-keygen asked 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 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:

    -----BEGIN RSA PRIVATE KEY-----

    Proc-Type: 4,ENCRYPTED

    DEK-Info: DES-EDE3-CBC,56C91DCFDF45E388

 

    MxnhXdGMmnFlR2cmjtF690uIYKLZUlbfVcXWRYwgxH21k0K6zicRE2YUDiNGikCW

    GNjB97uObN8JEyykvbQaXFdu5UJKO5ydE7YmBk3n/I6WRo+gNCig9+ty0LIMOg0J

    NIsvCdUi3+2ldsz8TRSRYPY0uZ3ddymKjIzePDx2WiacTB3VAomx7s3HhoFIBuTA

    7DwUJx0jDUsoF6vNs3LIZTOs/XuwRAttNRsKX2LFkAZpqRPjabohZ7HpQy2Y3yGF

    zv2kdAQXF769/YepaBzjEmt5OKx+NsWmi9DgaghhUsUZjPqZY+X/D8hXqCIMdSsB

    5uPuKC/OjfuersZTiNK1hh288fuFD2phQ8aHu2RCfpFXB21Vh5A8Bg9ZO1pqHfU2

    ngWrmdXOauOQxQ8+Pmh44N0dKPmmQ4sccpUgZe4aMplLKrarQOufcGX33JGAF0xc

    WyWjl14IZCpQdWbCO6rKEnWf6bgjuYyV9y2n6TjaIDgwMn3UV381LHCqxEsdERid

    X/at3BsPc2verLrN5qEDVpPJmdFr5WCghgds88DhuP8suQodbtlVidWj/rTd7fV+

    6RhsozJIkeCBwccQTJDJrMoTUi5eNwIO2g91Cjj7Fu2b3ir1lrOVg8OK5zsukFcY

    +Gcub8AJjOq8vRqNZ2o0SyXGcoORKIwqpMF9+IlaUGJ3n7THK4DbXwtzGeBIZiwH

    Gs4bzowFecPFh8PuvwUa1gIH+aPNsXZ0Jtkv72d3r9y9EBHNIkyh9KFDztFaFswY

    2BdXcnDfNmsRbtVvH4kFb0h2R1M2aaXsJFl0mvCtaOM=

    -----END RSA PRIVATE KEY-----

 

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 this private key to the openSSH-format. This can be done with puTTYgen as well.

Putting the public key to the remote server

To be able to log in to remote systems using a pair of keys, one will 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 >> authorized_keys

    [kb@wilma .ssh]$ rm ../identity.pub

 Further readings

http://www.oreilly.com/catalog/sshtdg/ SSH, The Secure Shell: The Definitive Guide written by Daniel J. Barret & Richard Silverman, published by O'Reilly

http://www.openssh.org/manual.html OpenSSH manual

How to handle StdErr and ExitCode

The job knows some parameters to handle the stderr and the exit code. These are

  • ignore_stderr
  • ignore_error
  • ignore_exit_code
  • raise_exception_on_error

As an example, we examine the command

<pre class="example">ls _unknown_folder_; exit 5;</pre>

This commmand has a stderr = "<code>ls: _unknown_folder_: No such file or directory</code>" and the exit code 5.

ignore_stdoutignore_errorraise_exception_on_error

ExitCode of the

command

ExitCode of the

job's task

Order goes to...
falsefalsetrue51error node
truefalsetrue51error node
falsetruetrue51error node
truetruetrue50next node
falsefalsefalse55next node
truefalsefalse55next node
falsetruefalse55next node
truetruefalse50next node

Further the job creates the parameters

  • std_out_output
  • std_err_output
  • exit_code

SSH Client Implementations

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.

Getting Started with the JITL SSH Job

The following article describes the basic use of the SSH job and applies to both the Trilead and JSch implementations.

A basic introduction to the authentication methods available for SSH and how they can be implemented with the JITL SSH job is available in:

Additional Features

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

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:

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

 If you use the job in a job chain then you can use these parameters in a next job of the job chain to handle the result.