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 >>
    Getting Started with 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 >>
        Distributing Public Keys Using the Key Distribution Tool >>
            Distributing Mainframe Server Keys
            Distributing Remote Server Keys
            Distributing Mainframe User Keys
            Distributing Remote User Keys
    Transferring Files >>
    Tunneling >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Advanced Information >>
    Man Pages >>
    Log Messages >>

Distributing Mainframe Server Keys

The server is run as a started task under the SSHD2 user as described in Section Running as a Started Task, one server on each LPAR that will be accessed.

Each system (LPAR) has its own /etc/ssh2 directory. A server key is generated for each system. The mainframe administrators can publish the fingerprints of these keys.

The remote users download the server public key on the first Secure Shell access to the mainframe and whenever the server key has been changed. This access must be interactive and the user must verify the key by its fingerprint and allow the Secure Shell client program to write it to the user's hostkey directory or file. The directory is $HOME/.ssh2/hostkeys for SSH Tectia Client on Unix and "%USERPROFILE%\Application Data\SSH\HostKeys" for SSH Tectia Client on Windows. OpenSSH clients store the host keys in the $HOME/.ssh/known_hosts file.

To set up client access to mainframe Secure Shell servers, the users must access all the mainframe systems, either using manual interactive connections or using a script similar to ssh-1st-connect2. When this is done, accessing the mainframe only requires the users to enter their passwords.

PreviousNextUp[Contents] [Index]

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

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




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now