[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     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).

Example

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

Key master.pub
Key maid.pub
Options allow-from=".*\.example\.org"
Key butler.pub
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.