Your browser does not allow storing cookies. We recommend enabling them.

SSH Tectia 
PreviousNextUp[Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server for IBM z/OS >>
    Using SSH Tectia Server for IBM z/OS >>
    Configuring the Server >>
    Configuring the Client >>
    Authentication >>
        Using the z/OS System Authorization Facility
        Server Authentication with Public Keys in File >>
        Server Authentication with Certificates >>
        User Authentication with Passwords
        User Authentication with Public Keys in File >>
        User Authentication with Certificates >>
        Host-Based User Authentication >>
        User Authentication with Keyboard-Interactive >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Examples of Use >>
    Man Pages >>
    Log Messages >>

Using the z/OS System Authorization Facility

SSH Tectia Server for IBM z/OS supports X.509 certificates and RSA keys managed by the z/OS System Authorization Facility (SAF). See Server Authentication and User Authentication. If SAF keys are going to be used, the users need permissions to access the relevant facilities.

SSH Tectia Server for IBM z/OS uses the Integrated Cryptographical Services Facility (ICSF) if the UseCryptoHardware configuration variable allows it (see Section Crypto Hardware Support) or keys and certificates are stored in the System Authorization Facility (SAF) and the keys are of type ICSF or PCICC (see Creating Server Host Key in SAF and Creating User Keys in SAF). SAF will control the use of cryptographic services if the CSFSERV class is activated and will control the access to cryptographic keys if the CSFKEYS class is activated.

The table below shows, for each argument of the UseCryptoHardware variable, the names of the resource profiles in the CSFSERV class that users must have access to.

UseCryptoHardware  Resources

* The resources shown for 3DES are not required on machines that have the CPACF feature.

When using private keys, the server or client user needs access to the CSFDSG resource in the CSFSERV class. The private keys can be secured by permitting access to a resource in the CSFKEYS class. The name of the resource is the label of the key in the ICSF key database.

See the chapter "Controlling Who Can Use Cryptographic Keys and Services" in the z/OS ICSF Administrator's Guide for instructions on how to use generic resource names, how to give permissions to user groups and connect users to groups, and how to define auditing.

The users (including the SSHD2 user) must have at least READ access to the IRR.DIGTCERT.LISTRING facility. If a user needs access to a key ring belonging to another user, he must have UPDATE access to the facility. This case will arise when using a KnownHostsEkProvider for checking host certificates, because host certificates are best entered as SITE keys and are not owned by the verifier.

PreviousNextUp[Contents] [Index]

[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2006 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice

Want to see how PrivX can help your organisation?

Are you a DEVELOPER accessing cloud hosts, are you a IT ADMIN managing access & credentials in your corporation, are you BUSINESS MANAGER and want to save money or are you responsible of IT SECURITY in DevOps