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 >>
    Using SSH Tectia Server for IBM z/OS >>
    Configuring the Server >>
    Configuring the Client >>
    Authentication >>
        Server Authentication with Public Keys >>
        User Authentication with Passwords
        User Authentication with Public Keys >>
        Host-Based User Authentication >>
            Client Configuration
            Server Configuration
            Optional Configuration Settings
        User Authentication with Keyboard-Interactive >>
    Troubleshooting SSH Tectia Server for IBM z/OS >>
    Examples of Use >>
    Man Pages >>
    Log Messages >>

Server Configuration

To allow host-based authentication with traditional public keys on the server, do the following steps as ServerUser:

  1. Create a file named .shosts in the home directory of ServerUser. The contents of this file should be the client's hostname, some tabs or spaces, and the user's username on the client.       ClientUser

    Make sure the .shosts is owned by ServerUser and its permissions are 0600.

  2. Check that the server user's home directory is owned by the user and its permissions are at most 0755 (or more restrictive, like 0700).

    If every user is allowed to write to the directory, there will be nothing to prevent them from overwriting the .shosts file with their own version with an entry for their client user, allowing them to authenticate to SSH Tectia Server as ServerUser.

Do the following steps as the server administrator:

  1. Copy the client's /etc/ssh2/ file over to the server. Note that this requires root permissions on the client, and optionally on the server as well.

    SSH Tectia Server is configured by default to look in one of two places on server for the host keys to use for host-based authentication:




    The server administrator can edit the UserKnownHosts keyword in the sshd2_config file to disable the use of the user-defined known hosts (they are allowed by default).

    If you want to allow host-based authentication to all users connecting from the client machine, you can add the public host key to /etc/ssh2/knownhosts. Root permissions are required for this method.

    If you want to allow host-based authentication only to some users, and if user-defined knownhosts are allowed, then you can instead add the keys to the $HOME/.ssh2/knownhosts directory.

    You have to name the client's public key as follows on the server:

    In the example, is the hostname the client is sending to the server. When DefaultDomain has been set on client, this name is always the long hostname (FQDN). This gives the server the client's public key so the server can verify the client user's identity based on the public key signature.

  2. In the sshd2_config file under the AllowedAuthentications keyword, add hostbased as an allowed method. For example:
    AllowedAuthentications hostbased,publickey,password
    If you want to allow multiple authentication methods, place the least interactive method first.
  3. Restart the server as instructed in Section Starting the Server.

To test that host-based authentication works, log in to client as ClientUser and run the following command:

$ ssh ServerUser@server uptime

You should get back the results of uptime on the server.

PreviousNextUp[Contents] [Index]

[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2006 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice


What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now