SSH Tectia  
Previous Next Up [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 >>
        Subconfigurations >>
        Ciphers and MACs >>
        Configuring Root Logins
        Restricting User Logins
        Subsystems
        Auditing >>
        Securing the Server >>
        Default sshd2_config Configuration File
        Default ssh_certd_config Configuration File
    Configuring the Client >>
    Authentication >>
    File Transfer Using SFTP >>
    File Transfer Using Transparent FTP Tunneling >>
    Tunneling on the Command Line >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Advanced Information >>
    Man Pages >>
    Log Messages >>

Restricting User Logins

By default, SSH Tectia Server does not impose any login restrictions in addition to those provided by the operating system. However, you can restrict connections based on host, username, or group.

The restrictions are defined in the sshd2_config file using the following syntax:

keyword             pattern

Note: All the patterns used in the examples below are in accordance with the egrep syntax, which is the default regex syntax in SSH Tectia Server for IBM z/OS.

Examples of commonly used regular expressions and conventions with egrep syntax:

  • .* matches everything
  • . any character
  • \. literal .
  • [:alpha:]+ any lower or uppercase alphabet character one or more times
  • (80|8080) either 80 or 8080

The regex syntax can be chosen by using the metaconfig block in the beginning of ssh2_config and sshd2_config:

## SSH CONFIGURATION FILE FORMAT VERSION 1.1
## REGEX-SYNTAX egrep
## end of metaconfig

Possible values of REGEX-SYNTAX are ssh, egrep, zsh_fileglob and traditional. For more information, please see the sshregex man page (Appendix sshregex).

Previous versions of SSH Secure Shell (3.1 and earlier) always use the zsh_fileglob syntax.

Available keywords are the following:

  • AllowHosts/DenyHosts

    Login is allowed/denied from hosts whose name matches one of the specified patterns.

    Example 1: Listing complete hostnames

    AllowHosts          localhost, example\.com, friendly\.example   
    

    This allows connections only from specified hosts.

    Example 2: Using patterns with hostnames

    AllowHosts          h..s.\..* 
    

    This pattern matches, for example, house.foobar.com, house.com, but not house1.com. Note that you have to input the string "\." when you want to specify a literal dot.

    Example 3: Using patterns with IP addresses

    AllowHosts          ([[:digit:]]{1\,3}\.){3}[[:digit:]]{1\,3}
    

    This pattern matches any IP address (xxx.xxx.xxx.xxx). However, some host's hostname could also match this pattern.

    Example 4: Using \i

    AllowHosts          "\i192.*\.3"
    

    When \i is used in the beginning of a pattern, only the host IP addresses are used. The above pattern matches, for example, 192.0.0.3.

  • AllowSHosts/DenySHosts

    The .shosts, .rhosts, /etc/shosts.equiv and /etc/hosts.equiv entries are honored only for hosts whose name matches one of the specified patterns. It is recommended to use these keywords with host-based authentication.

  • AllowUsers/DenyUsers

    Login is allowed/denied as users whose name matches one of the specified patterns.

    Example 1: Using complete usernames

    DenyUsers           devil@evil\.example,warezdude,1337
    

    This denies login as devil when the connection is coming from evil.example. It also denies login (from all addresses) as warezdude and as user whose UID is 1337.

    Example 2: Using patterns with usernames

    AllowUsers          "sj*,s[:digit:]+,s(jl|amza)" 
    

    This pattern matches, for example, sjj, sjjj, s1, s123, and samza but not s1x or slj.

    Example 3: Using \i

    AllowUsers          "sjl@\i192.*\.3"
    

    This would allow login as user sjl from only those hosts whose IP address matches the specified pattern.

  • AllowGroups/DenyGroups

    Login is allowed/denied when one of the groups the user belongs to matches one of the specified patterns.

    Example 1

    AllowGroups         root,staff,users
    

For more information on keywords, see the sshd2_config man page (Appendix sshd2 config).

Previous Next Up [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