Your browser does not support HTML5 local storage or you have disabled it. Some functionality on this site, including saving your privacy settings and offering you special discounts, uses local storage and may not work with local storage disabled. We recommend allowing the use of local storage in your browser. In some browsers, it is the same setting used for disabling cookies.

Tectia

Using the Authorization File

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.

===AUTO_SCHEMA_MARKUP===