Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

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 >>
    Configuring the Client >>
    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 >>
        User Authentication with Certificates >>
        Host-Based User Authentication >>
            Client Configuration
            Server Configuration
            Optional Configuration Settings
        User Authentication with Keyboard-Interactive >>
        Distributing Public Keys Using the Key Distribution Tool >>
    Transferring Files >>
    Tunneling >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Advanced Information >>
    Man Pages >>
    Log Messages >>

Optional Configuration Settings

To make the host-based authentication more secure, you may want to consider the following optional configuration settings:

  • With the AllowSHosts and DenySHosts keywords in the sshd2_config file you can filter the .shosts, .rhosts, /etc/hosts.equiv and /etc/shosts.equiv entries.
  • If you want to allow only global configuration files (/etc/hosts.equiv and /etc/shosts.equiv), make sure that you have the following entry in your sshd2_config file:
    IgnoreRhosts             yes
    

    After this modification the .shosts and .rhosts files will not be used in host-based authentication.

  • To force an exact match between the hostname that the client sends to the server and the client's DNS entry, make sure that you have the following definition in your /etc/ssh2/sshd2_config file:
    HostbasedAuthForceClientHostnameDNSMatch yes
    
    In this case, make sure the /etc/hosts file has the fully qualified hostname listed before the short hostname, for example:
    123.123.123.123   client.example.com   client
    

    Even if you are not using /etc/hosts as your primary resolver, you may need to add entries to it for the client and the server to allow them to resolve each other's fully qualified domain names (if they are not able to do so otherwise).

    Please note that when HostbasedAuthForceClientHostnameDNSMatch is used, host-based authentication through NAT (Network Address Translation) will not work.

PreviousNextUp[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

===AUTO_SCHEMA_MARKUP===