Dovetailed Technologies

1. Basic Installation and Configuration

1.1 Introduction

This guide is designed to help systems programmers quickly configure z/OS - OpenSSH. This guide assumes OpenSSH APAR OA54299 is installed on z/OS V2R2 or V2R3 or a later z/OS release. With this APAR installed, IBM z/OS OpenSSH will directly use the CPACF instruction, when present, to implement symmetric ciphers and MAC algorithms. This configuration is preferred over our prior recommendation to use ICSF.

While the procedures in this document will work in most environments, users should reference the appropriate IBM documentation as appropriate. The primary reference is the z/OS OpenSSH User's Guide. This guide will call out specific sections of the User's Guide or other documents for additional information.

[Note]Updated for OpenSSH running on z/OS V2R2 or V2R3 with APAR OA54299

This version of the quick install guide has been updated specifically for the the new functionality added to OpenSSH with this APAR: CPACF support. If you do not have this APAR installed, refer to IBM Ported Tools OpenSSH v1.3 - Quick Install Guide, which is compatible with z/OS OpenSSH V2R2 / V2R3.

Topics covered in this guide:

  • Prerequisites, service planning

  • Language Environment tuning considerations

  • ICSF support for secure random numbers via /dev/random

  • Configuration files, started task, etc.

  • z/OS Communications Server TCP/IP, Resolver and syslogd considerations

  • CPACF support for hardware accelerated ciphers and MACs

  • Managing the /tmp filesystem

Note: The included examples assume that you are running RACF as your system security product. z/OS OpenSSH will also work with CA-ACF2 and CA-TSS, but you will be required to translate RACF commands as shown to those products. If you have one of those products and would like to contribute tested examples, please contact us.

1.2 Prerequisites

This guide assumes that you are running OpenSSH on z/OS V2V2 or later. Using this product and exploiting these features requires:

  • APAR OA54299: provides CPACF support on V2R2 or V2R3

  • CPACF - processor feature 3863 (free and enabled by default in most countries)

  • ICSF installed and running (even if you don't have a co-processor card)

1.3 Install / Service Planning

  • Review and install as appropriate any service for OpenSSH (HOS2220 or HOS2230). See upgrade ZOSV2R2/3 Subset ZOSOSSH

  • Be sure to install the PTF for APAR OA54299.

  • Review and install as appropriate ICSF and its required service.

1.4 Check file attributes and ownership

From a z/OS Unix shell, check the permissions and owner of the following directories:

$ ls -ld /etc/ssh /var/empty /var/run
drwxrwxrwx1  2 STC1  2  SYS1        8192 Feb 25 14:30 /etc/ssh
drwxr-xr-x   3 STC1     SYS1        8192 Feb 21  2013 /var/empty
drwxr-xr-x   2 STC1     SYS1        8192 Jan 29 15:09 /var/run

Check the permissions, extended attributes, and owner of the following files:

$ ls -El /usr/sbin/sshd
-rwxr--r--1 ap--  2 STC1  2  SYS1     8331264 Feb 25 14:30 /usr/sbin/sshd

$ ls -El /bin/ssh* /bin/scp /bin/sftp                                                                                               
-rwxr-xr-x  -p--3 2 STC1     SYS1     6041600 Feb 25 14:30 /bin/scp
-rwxr-xr-x  -p--  2 STC1     SYS1     6180864 Feb 25 14:30 /bin/sftp
-rwxr-xr-x  -p--  2 STC1     SYS1     7536640 Feb 25 14:30 /bin/ssh
-rwxr-xr-x  --s-  2 STC1     SYS1     5693440 Feb 25 14:30 /bin/ssh-add
-rwxr-xr-x  --s-  2 STC1     SYS1     5476352 Feb 25 14:30 /bin/ssh-agent
-rwxr-xr-x  --s-  2 STC1     SYS1     5918720 Feb 25 14:30 /bin/ssh-keygen
-rwxr-xr-x  --s-  2 STC1     SYS1     6070272 Feb 25 14:30 /bin/ssh-keyscan

$ ls -El /usr/lib/ssh 
drwxr-xr-x        2 STC1     SYS1        8192 Oct 22  2011 IBM
-rwxr-xr-x  -p--  2 STC1     SYS1     1122304 Feb 25 14:30 sftp-server
-rwxr-xr-x  --s-  2 STC1     SYS1     3866624 Feb 25 14:30 ssh-askpass
-rwsr-xr-x  ----  2 STC1     SYS1     6418432 Feb 25 14:30 ssh-keysign
-rwxr-xr-x  aps-  2 STC1     SYS1       57344 Feb 25 14:30 

The permissions bits should match this column.


The owner must be UID=0; one of your UID=0 userids should be displayed.


The extended attributes should match this column. a="APF authorized" p="Program Controlled" s="allow shared address space"

Reference: OpenSSH User's Guide: "Steps for verifying the prerequisites for using OpenSSH"

1.5 Language Environment Tuning

OpenSSH uses the LE XPLINK libraries, and IBM recommends the following:




  • SCEERUN and SCEERUN2 must be program controlled

  • Implement samples SCEESAMP(CEEWLPA) and SCEESAMP(EDCWLPA). We recommend implementing both of these as shipped.

Note: OpenSSH will still run if recommended XPLINK modules are not placed in LPA. This is something that you can defer for your next system maintenance window.


1.6 Using ICSF and /dev/random

Generation of secure random numbers is key to using OpenSSH (or any cryptographic tool). OpenSSH requires a working /dev/random device in order to run (the obsolete alternative ssh-rand-helper has been removed from OpenSSH). On z/OS Unix, /dev/random is provided by ICSF's CSFRNG service. In the past this required that you have a co-processor card, but with the "A0" or later level of ICSF (HCR77A0/A1) you don't need a co-processor card - ICSF will generate a cache of secure random numbers using CPACF instructions as appropriate.

Without /dev/random support, OpenSSH will fail to start with the following message:

FOTS1949 PRNG is not seeded. Please activate the 
Integrated Cryptographic Service Facility (ICSF)

Assuming that ICSF is running and supports the CSFRNG service, all you need to do is to authorize your users to this service. For most environments, it will be acceptable to permit all users to the CSFRNG service:


To verify that /dev/random is working, issue this command from a z/OS UNIX shell and userid with normal priviledges (and CSFRNG access). This should display some random data in hex:

$ head /dev/random | od -x

Reference: OpenSSH User's Guide: "Using hardware support to generate random numbers"

1.7 Creating configuration files

Copy the sample configuration files to the /etc/ssh directory.

If you are running a previous version of OpenSSH you will want to review the differences between your current configuration files and these samples to see if any site-specific configuration options should be migrated to the new release. In particular, if you have updated zos_ssh_config or zos_sshd_config to add CiphersSource and MACsSource keywords, you will probably want to remove these. See section Chapter 2, Exploiting crypto hardware acceleration for more information.

Note: You must use a UID=0 userid for this:

$ cd /samples
$ cp -p moduli          /etc/ssh
$ cp -p ssh_config      /etc/ssh
$ cp -p sshd_config     /etc/ssh
$ cp -p zos_ssh_config  /etc/ssh
$ cp -p zos_sshd_config /etc/ssh	

Note: All of the above files in /etc/ssh should be owned by a UID=0 userid and have permissions 644:

-rw-r--r--   1 STC1     SYS1      242153 Jan 15 17:08 moduli
-rw-r--r--   1 STC1     SYS1          3483 Jan 15 17:08 ssh_config
-rw-r--r--   1 STC1     SYS1          4685 Jan 15 17:08 sshd_config
-rw-r--r--   1 STC1     SYS1          1158 Jan 15 17:08 zos_ssh_config
-rw-r--r--   1 STC1     SYS1          1209 Jan 15 17:08 zos_sshd_config

Reference: OpenSSH User's Guide: "Steps for creating or editing configuration files"

1.8 Creating SSHD server keys

You must generate one or more public/private key pairs that are used for authentication of your SSHD server. Each client that connects to the server will either already have one of the public keys (aka "host fingerprint") or will be required to accept your server's public key as proof of the server's identity.

For more information on SSH key authentication, see the recording of our webinar: IBM Ported Tools for z/OS: Key Authentication

Server keys can be stored either in protected UNIX files or in SAF/RACF keyrings. Most installations will choose to use files, which is covered below. For information on how to use SAF/RACF keyrings, see our webinar: IBM Ported Tools for z/OS: Using Key Rings

The following commands can be executed by a UID=0 userid to create all variants of the server key pairs. It will not overwrite existing keys of a given type, so it can be used safely:

$ cd /etc/ssh
$ ssh-keygen -A
ssh-keygen: generating new host keys: RSA1 RSA DSA ECDSA

This should result in four pairs of private/public key files with the following permissions, all owned by a UID=0 userid:

$ ls -al *key*
-rw-------   1 STC1     SYS1         668 Feb 25 15:00 ssh_host_dsa_key
-rw-r--r--   1 STC1     SYS1         606 Feb 25 15:00
-rw-------   1 STC1     SYS1         227 Feb 25 15:00 ssh_host_ecdsa_key
-rw-r--r--   1 STC1     SYS1         178 Feb 25 15:00
-rw-------   1 STC1     SYS1         981 Feb 25 15:00 ssh_host_key
-rw-r--r--   1 STC1     SYS1         646 Feb 25 15:00
-rw-------   1 STC1     SYS1        1679 Feb 25 15:00 ssh_host_rsa_key
-rw-r--r--   1 STC1     SYS1         398 Feb 25 15:00

Reference: OpenSSH User's Guide: "Steps for setting up server authentication when keys are stored in UNIX files"

1.9 Set up SSHD server userids

Your SSHD server will use two SAF/RACF userids (besides the actual userids that clients sign on with):

  1. The privileged UID=0 userid used to start the started task (here we use "SSHDAEM")

  2. The unprivileged "privilege separation" userid (this must be "SSHD", or have an alias of "SSHD")

The privileged started task userid can be an existing UID=0 userid, like OMVSKERN, but we recommend creating a new userid, defined like OMVSKERN:

    OMVS(UID(0) HOME('/') PROGRAM('/bin/sh'))

The privileged started task userid must have read access to BPX.DAEMON -


Note: If your system has the FACILITY/BPX.POE defined, then the SSHDAEM userid will require READ access. If the SERVAUTH class is active, then the SSHDAEM userid will require authorization to access incoming socket connections.

Create the unprivileged "privilege separation" userid, where ggg is an unused groupid and uuu is an unused non-zero uid (you may alternatively use the AUTOGID and AUTOUID keywords if you have enabled the BPX.NEXT.USER profile) -

    PROGRAM(’/bin/false’)) NOPASSWORD  	

Reference: OpenSSH User's Guide: "Step for creating the sshd privilege separation user" and "Starting sshd as a stand-alone daemon"

1.10 Create SSHD server started task

The best way to start your SSHD server is by using a started task proc:

//SSHD PROC                                                   
//     PARM='PGM /bin/sh -c /etc/ssh/'                 

This proc executes a shell script /etc/ssh/ that you must create:

export NLSPATH=$NLSPATH:/usr/lib/nls/msg/%L/
export _EDC_ADD_ERRNO2=1
nohup /usr/sbin/sshd -f /etc/ssh/sshd_config & 
sleep 1

This script should have permissions "700" and be owned by a UID=0 userid.

-rwx------   1 STC1     SYS1         141 Feb 26  2013

The SSHD started task must be configured to start with the privileged userid "SSHDAEM" that you setup in the prior section:


To start sshd, issue the following MVS command:


Verify that the proper userid and group were assigned to the SSHD started task by examining the system log:

S SSHD                                                            
$HASP100 SSHD     ON STCINRDR                                     
SSHDAEM, GROUP OMVSGRP                                           
$HASP373 SSHD     STARTED                                         

Note: like FTPD, this started task will quickly terminate, but it will spin off an OMVS address space with jobname "SSHDn".


1.11 TCP configuration

Using the default sshd_config settings, SSHD listens on port 22 on all stacks. Since this is a privileged port number, only programs running as superuser are allowed to listen on this port. We recommend that for your next IPL that you also reserve this port in PROFILE.TCPIP, since it also serves to document usage. In the following example template, we also cause the SSHD started task to be started after TCPIP has started:

    SSHD                 ; SSHD Server (STC SSHDn)   
    22 TCP SSHD* NOAUTOLOG  ; Ported Tools SSHD server

Reference: OpenSSH User's Guide: "Steps for creating or editing configuration files" Step 4

1.12 Verify z/OS DNS / Resolver operation

The ssh client will perform DNS lookups on target host names. Also, by default, the sshd server will lookup remote host names and check that the resolved name maps back to the IP address (warnings will be logged otherwise) . If the z/OS DNS client (the "Resolver") is not working properly, these requests might hang before timing out.

A full z/OS DNS server is not required to run OpenSSH, but most shops will want to run a "caching-only server" connected to their corporate DNS servers. At minimum you should at least configure the z/OS resolver so that DNS requests do not hang.

To verify that your z/OS resolver is working properly, issue the following command from a z/OS UNIX shell. Try known and unknown host names to verify that neither hang:

$ host
EZZ8321I has addresses
EZZ8322I aliases:,,

$ host                                                                                     
EZZ8342I Unknown host 


1.13 Configuring the syslogd daemon

SSHD server will log messages to the z/OS Communications Server syslogd facility using a local UNIX datagram socket (/dev/log).

IBM FTPD, TELNETD, IDS, and other z/OS Comm Server applications use syslogd for logging and tracing as well. Although some of these z/OS Comm Server applications will log to the z/OS console if syslogd is not running, the OpenSSH SSHD server will not. Therefore, it is important to have syslogd running in local mode (-i) so that SSHD server log messages are available.

Starting with z/OS 1.11, significant enhancements were made to syslogd -

  • performance improvements

  • improved operator interfaces

  • automatic archival to MVS data sets

  • ISPF syslogd viewer

The OpenSSH SSHD server by default will log all messages with INFO severity or higher to the local syslogd "AUTH" facility.

You should verify that syslogd is configured and started on your z/OS system and that your /etc/syslog.conf file is configured so that messages to the AUTH facility will be logged to some file. For example:

# log any messages to AUTH facility (sshd)
auth.* /tmp/syslogd.auth.log -X 


1.14 Verify basic functionality

Before we move on, lets verify the basic functionality of your SSHD server. To do this, you will need to install an SSH client, like PuTTY on your workstation on a network that can connect to your z/OS system on port 22.

Note: You will want to test an ssh session to an unprivileged z/OS userid that has an OMVS segment and home directory. If you have a non UID=0, unprivileged TSO userid that can get into the TSO OMVS shell, then use that.

C:> putty 
 - or -
C:> putty zosuser@ 
Using username "zosuser".'s password: ******

If successful, the above will place you in an SSH session with an interactive z/OS UNIX login shell. Once you have a non-TSO UNIX shell, you can use the ssh client command to connect to other hosts. For example, you can also connect to the same z/OS system using the loopback address:

/u/home/zosuser> ssh zosuser@
The authenticity of host ' (' can't be established.
RSA key fingerprint is 22:cb:9c:30:9d:98:c8:4f:45:a8:ac:00:e5:8e:62:af.
Are you sure you want to continue connecting (yes/no)? yes's password: ******
/u/home/zosuser> exit
/u/home/zosuser> (back to the first connection) 

Now is also a good time to verify your syslogd configuration. Look at the end of the logfile that you configured in /etc/syslog.conf:

$ tail /tmp/syslogd.auth.log
Feb 14 21:11:23 S0W1 sshd[67174502]: Port of Entry information retained for ... 
Feb 14 21:11:24 S0W1 sshd[67174502]: Accepted password for zosuser from ...

Copyright© 2009-2017 Dovetailed Technologies, LLC. All rights reserved.
Co:Z® is a registered trademark of Dovetailed Technologies, LLC.