SSH (Secure Shell)
Titan provides the ability to directly transfer data sets and automatically translate between ASCII and EBCDIC via the SSH (secure shell) protocol. The SSH protocol is widely used on Unix systems to carry out secure (encrypted) file transfers. SSH software is also available for Windows and Macintosh machines. SSH is available on Titan as part of Titan’s Unix System Services (USS). Because a userid must be specifically authorized to use USS, users who need this facility should contact the NIH IT Service Desk. A userid containing a $ cannot be authorized to use USS.
How to Begin
The SSH server on Titan runs on port 9022 instead of the standard port 22. Be sure to change the setting in your SSH client software.
You must create an .ssh2 subdirectory under the home directory for your USS-enabled Titan userid.
Key Authentication
If you use key authentication:
· Store the public member of the key pair in the .ssh2 directory in SECSH Public Key File format, sometimes called commercial key format.
· Save the public key file as an EBCDIC text file on Titan.
Uploading the Public Key
The simplest way to upload a public key is through a FTP text file transfer. Once your FTP session is established, do the following:
· Access your .ssh2 directory by using the command: cd /u/userid/.ssh2
· Store the file you want to transfer as a text file. The file must have the proper line terminators for the particular operating system (e.g., nl for Unix, CR/LF for Windows) on the remote host.
· Create a file named “authorization” in the Titan .ssh2 subdirectory
· Insert a line in the authorization file containing:
Key publickeyfilename (where publickeyfilename is the name of the public key file)
Below is an example of an SECSH format key file:
---- BEGIN SSH2 PUBLIC KEY ----
Subject:USERID
Comment: "1024-bit rsa, userid@test, Tue Nov 29 2005 09:14:25 -0500"
AAAAB3NzaC1yc2EAAAADAQABAAAAgQDDSRuot37WD4T1odflyzXc+0KaU5yEjEs8ugSWkD
S12/H+JbcSb/EcyKmiugHJQcE1mTV6xqd4lxtKqO5iVKk3G6TqZ9VGkTngKYMISpUYjPja
b/9ULN3dl/WAbl2UXdn88vqCQNPRF1tRa5agGEs6GhCtVASwjV6uOjgaCFv6ww==
---- END SSH2 PUBLIC KEY ----
Once the preceding configuration has been completed, you can use your sftp (Secure File Transfer Protocol) client to transfer files to/from Titan mainframe data sets.
In the examples below:
userid1 belongs to the person logging on from the remote system
userid2 belongs to the owner of the data set (not necessarily the same as the person logging on)
The first command in your sftp session or script must be:
cd /ftadv:P=XLATE/___userid2.
This command enables ASCII-EBCDIC translation and sets your target directory to the userid under which you will be storing or from which you will be retrieving data sets.
The following is a sample Unix shell script that allocates a new data set and uploads a file to it:
alloc="mgmtclas(temp) dataclas(dataf)"
omvsnm1=\'userid2.tectia.mput.#1\'
omvsnm2=\'userid2.tectia.mput.#2\'
ssh2 -v -oPort=9022 userid1@titan.nih.gov /bin/sh << HERE
tso "delete $omvsnm1 nvsam"
tso alloc \
"da($omvsnm1) new $alloc"
tso "delete $omvsnm2 nvsam"
tso alloc \
"da($omvsnm2) new $alloc"
HERE
sftp2 -v -oPort=9022 -B sftp2.bat userid1@titan.nih.gov
exit
The script sftp2.bat is:
cd /ftadv:P=XLATE/___userid2.
pwd
cd tectia.
pwd
mput mput*
quit
SSH transfers initiated on Titan are carried out in batch jobs.
(job card)
/*JOBPARM SYSAFF=SYS4
//*
//* SFTLS – Create data set containing output of sftp ls
//* command, which will provide a list of files on the remote
//* host
//* dsname below is for data set that contains remote host directory listing
//SCR EXEC DSSCR,NAME=’dsname”
//*
//SFTP EXEC SSZP
//* DDNAME of next statement must be STDOUTPR; DATACLAS=DATAV
//* creates a variable blocked data set
//STDOUTPR DD DSN=dsname,DISP=(NEW,CATLG),
// MGMTCLAS=TEMP,DATACLAS=DATAV
//* DDNAME of next statement must be SFTCMDS
//*
//SFTCMDS DD *
open user@remotehost
ls
quit
//SYSTSIN DD *
%SSZRFT
(job card)
/*JOBPARM SYSAFF=SYS4
//*
//* Example to use sftp to ‘upload’ an MVS data set to a
//* remote host.
//*
//*
//*
//SFTP EXEC SSZP
//* DDNAME of next statement must be the same as value for
//* //DD: parameter below
//TECTIA DD DSN=dsname,DISP=SHR
//*
//SFTCMDS DD *
open user@remotehost
sput //DD:TECTIA remotefilenm
ls
quit
//SYSTSIN DD *
%SSZRFT
(job card)
/*JOBPARM SYSAFF=SYS4
//*
//* Example for using SFTP to ‘download’ a file from a remote
//* host to an MVS data set.
//*
//* Next statement scratches the data set if it already exists.
//SCR EXEC DSSCR,NAME=’dsname’
//*
//SFTP EXEC SSZP
//* DDNAME of next statement must match value for //DD: specified
//* below. ‘/ftadv:P=MVS/’ is optional; it specifies ascii-ebcdic
//* conversion, which is done by default
//TECTIA DD DSN=dsname,DISP=(NEW,CATLG),
// MGMTCLAS=TEMP,DATACLAS=DATAF
//* DDNAME for statement below must be SFTCMDS; the ls command provides
//* a directory listing of the files on the remote host.
//* the open command establishes the connection to the remote host
//SFTCMDS DD *
open user@remotehost
ls
sget remotefilenm /ftadv:P=MVS///DD:TECTIA
quit
//SYSTSIN DD *
%SSZRFT -v
(jobcard)
/*JOBPARM SYSAFF=SYS4
//* SCPUPL – Example for running SCP using SSZP PROC
//* Example shows ‘uploading’ a Titan data set to a remote host
//SCP EXEC SSZP
//* DDNAME of next statement must match value specified for
//* //DD: parameter below. ‘/ftadv:P=XLATE/’ is optional; it
//* specifies ascii-ebcdic translation, which occurs by default
//TECTIA DD DSN=uid.dsname,DISP=SHR
//SYSTSIN DD *
%SSZRCP -v +
/ftadv:P=XLATE///DD:TECTIA +
user@remotehost:filename
/*
(jobcard)
//*
/*JOBPARM SYSAFF=SYS4
//* SCPDNL – Example for running SCP using SSZP PROC
//* This example ‘downloads’ a file from a remote host
//* to an MVS data set on titan
//*
//SCR EXEC DSSCR,NAME=’dsname’
//SFTP EXEC SSZP
//* DDNAME of next statement must be the same as value specified
//* after //DD: below
//TECTIA DD DSN=user.dsname,DISP=(NEW,CATLG),
// MGMTCLAS=TEMP,DATACLAS=DATAF
//*
//SYSTSIN DD *
%SSZRCP -v +
user@remotehost:filenm //DD:TECTIA
/*
Updated: 10/13/2010
Back to Network Access to Titan
For assistance, contact the NIH IT Service Desk and ask to speak with a SSH consultant.