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 >>
    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 >>
            Enabling Public-Key Authentication
            Using the Authorization File
            Using Keys Generated with OpenSSH
        User Authentication with Certificates >>
        Host-Based User Authentication >>
        User Authentication with Keyboard-Interactive
    System Administration >>
    File Transfer Using SFTP >>
    Secure File Transfer Using Transparent FTP Security >>
    Tunneling >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Man Pages and Default Configuration Files >>
    Log Messages >>

Using the Authorization File

SSH Tectia Server for IBM z/OS requires an authorization file that lists the user public keys that are authorized for login.

The default location for the authorization file is $HOME/.ssh2/authorization. The file location can be changed with the AuthorizationFile option in the sshd2_config file.

The authorization file contains a list of public key filenames each preceded by the keyword Key. If there is more than one Key, they are all authorized for login.

Authorization File Options

It is possible to define different settings in the authorization file depending on which key is used in public-key authentication. The authorization file has the same general syntax as the sshd2_config configuration file. The following keywords may be used:

  • Key

    This is followed by the filename of a public key in the user configuration directory (by default, $HOME/.ssh2) that is used for identification when contacting the host. If there is more than one key defined, they are all acceptable for login.

  • Options

    This keyword, if used, must follow the Key keyword above. The various options are specified as a comma-separated list.

    The following Options can be used:

    • allow-from and deny-from

      In addition to public-key authentication, the canonical name of the remote host must match the given pattern(s). These parameters follow the logic of {Allow,Deny}Hosts keyword of sshd2_config. Specify one pattern per keyword; multiple keywords can be used.

    • command="command"

      This is used to specify a "forced command" that will be executed on the server side instead of anything else when the user is authenticated. The command supplied by the user (if any) is put in the environment variable SSH2_ORIGINAL_COMMAND. The command is run on a pty if the connection requests a pty; otherwise it is run without a tty. Quotes may be used in the command if escaped with backslashes.

      This option might be useful for restricting certain public keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. Note that the client may specify TCP/IP and/or X11 forwarding, unless they are explicitly prohibited (see no-port-forwarding).

    • environment="NAME=value"

      Specifies that the string is to be added to the environment when logging in using this key. Environment variables set this way override other default environment values. Multiple options of this type are permitted.

    • idle-timeout=time

      Sets idle timeout limit to time either in seconds (s or nothing after the number), in minutes (m), in hours (h), in days (d), or in weeks (w). If the connection has been idle (all channels) this long, the connection is closed.

    • no-port-forwarding

      Forbids TCP/IP forwarding when this key is used for authentication. Any port forward requests by the client will return an error. This is useful in combination with the command option.

    • no-agent-forwarding

      Forbids authentication agent forwarding when this key is used for authentication.

    • no-pty

      Prevents tty allocation (a request to allocate a pty will fail).


Your authorization file could, for example, contain the following:

Options allow-from=".*\.example\.org"
Options deny-from=".*\.evil\.example",no-pty

When someone now logs in using the master key, the connection is not limited in any way by the authorization file. However, if the maid key is used, only connections from certain hosts will be allowed. And if the butler key is used, connections are denied from certain hosts, and additionally the allocation of tty is prevented.

PreviousNextUp[Contents] [Index]

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

Copyright © 2011 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