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 >>
        Server Configuration Files >>
        Defining Subconfigurations >>
        Configuring Ciphers and MACs >>
        Configuring Root Logins
        Restricting User Logins
        Configuring Code Pages
        Defining Subsystems
        Auditing >>
        Securing the Server >>
            Restrictions to System Administration
            Restrictions to File Transfer
            Restrictions to Tunneling
    Authentication >>
    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 >>

Restrictions to System Administration

Secure system administration is the traditional use case for Secure Shell.

Disabling Root Login

Usually, allowing direct root logins from the network is a bad idea. It is better to use forced commands to automate tasks requiring privileges (described in Section Forced Commands below), and make people use su or sudo to elevate privileges otherwise.

In addition to AllowUsers and DenyUsers, you can easily disable root logins with passwords (Section Configuring Root Logins). Put the following to your sshd2_config:

PermitRootLogin     nopwd

This way, jobs automated with forced commands will work.

Disabling Tunneling

If you are sure you or your users do not need to create tunnels (possibly going around firewall restrictions or such), you can disable tunneling (port forwarding) altogether by adding the following to your sshd2_config:

AllowTcpForwarding       no

If you need more fine-grained control, consider using AllowTcpForwardingForUsers (and related keywords DenyTcpForwardingForUsers, AllowTcpForwardingForGroups and DenyTcpForwardingForGroups). With ForwardACL you can even allow and deny tunnels based on originator and destination (based on the IP address and port). See Tunneling.

Disabling Terminal Access

If you only want to enable file transfers or tunneling for users in group users, you can disable terminal access by adding the following to your sshd2_config:

Terminal.DenyGroups      users

Other related keywords that can be used are: Terminal.AllowUsers, Terminal.DenyUsers and Terminal.AllowGroups.

It is recommended to deny also agent forwarding if Terminal Access is denied in sshd2_config.

AllowAgentForwarding     no

Note that the users will be able to use SFTP and other subsystems defined in the SSH Tectia Server configuration. Any other "exec" and "shell" requests will be denied for the users. This includes forced commands with public keys described in Section Forced Commands and the legacy style password changing when performed as forced command.

Forced Commands (with Public Keys)

If you have maintenance jobs requiring non-interactive access to your server, use public-key authentication and forced commands. This way, if the private key is compromised, the public key cannot be used to perform anything other than the predetermined command on the server. (This is, of course, also bad, but it would be worse if the malicious attacker would have unrestricted access to the machine.)

Do not use the root account for jobs where it is not absolutely necessary.

You can set up a forced command in the authorization file.

options command="tar zxvf - /usr/local"

This would, on a successful login with, force a backup job to start.

You can also use the command that was given on the ssh2 command line:

options command="echo $SSH2_ORIGINAL_COMMAND"

Running ssh2:

% ssh2 localhost kukkuu
Authentication successful.

For more information on the public-key options in the authorization file, see Using the Authorization File.

Note that if the user or the user's group has been denied terminal access (with the Terminal.DenyUsers or Terminal.DenyGroups keywords), also forced commands will be denied.

Restricting Connections

SSH Tectia Server can be configured to reject connection attempts from unknown hosts. For example the following allows connections only from the internal network IP addresses and from an external host with the IP address

AllowHosts               \i10\.1\..*,\i195\.20\.116\.1

Please see Section Restricting User Logins for information on the regular expression syntax and for more configuration examples and options.

On systems with several network interfaces, SSH Tectia Server can also be bound to a specific network interface so that the server can be only accessed from the intended network. For example, the following will bind the listener to address using port 2222:

Port                 2222


SSH Tectia Server logs are most important for auditing. The logs also provide troubleshooting information, for example, when user authentication fails and a user is unable to log in. Please see Section Auditing for more information.


It is recommended to notify the users before they decide to log in that their actions are logged. In some jurisdictions this is required.

To display for example the following text to the users before login, the banner message saved to name /opt/tectia/etc/ssh_banner_message can be used.

Unauthorized use of this system is prohibited.
All actions are logged.

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


Highlights from the SSH.COM blog:

  • Cryptomining with the SSH protocol: what big enterprises need to know about it

    Cryptomining malware is primarily thought of as targeting desktops and laptops and is used to hijack system resources to mine cryptocurrency.
    Read more
  • SLAM the door shut on traditional privileged access management

    Did you know that something as trivial-sounding as granting access for your developers or third parties to a product development environment can throw a gorilla-sized monkey wrench into your operations and productivity?
    Read more
  • We broke the IT security perimeter

    Everyone understands the concept of a security perimeter. You only gain access if you are identified and authorized to do so.
    Read more