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