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

Using Conventional Public Keys

Client Configuration

To enable host-based authentication with conventional public keys on the client, do the following as ClientUser:

  1. Generate a host key. If Tectia Server has been installed on the same machine, the host key pair /etc/ssh2/hostkey and /etc/ssh2/hostkey.pub has been generated during installation and you can skip this step. Otherwise, give the following command:

    # ssh-keygen-g3 -P -H hostkey
    

    Optionally, you can define a custom location or name for the host key in the ssh-server-config.xml file. If Tectia Server is not installed on the client host, you can create the configuration file manually and save it in the /etc/ssh2 directory.

  2. Add the following line in the ssh-broker-config.xml file:

    <authentication-methods>
      <auth-hostbased />
      ...
    </authentication-methods>
    

    Also other authentication methods can be listed. Place the least interactive method first (this means usually the host-based method).

Server Configuration

Do the following as the server administrator:

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

    Tectia Server looks for the host keys to use for host-based authentication in the /etc/ssh2/trusted_hosts directory on Unix and in the "<INSTALLDIR>\SSH Tectia Server\trusted_hosts" directory on Windows.

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

    client.example.com.ssh-dss.pub
    

    In the example, client.example.com is the host name that the client is sending to the server. When the server receives the client's public key, it forms a path based on the host name and the key type (ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, or ecdsa-sha2-nistp521) and compares the received public key to the key on the disk. If the public key matches and the user's login name in the remote end matches the name the user is trying to log in on the server, the user is let in after the signature check.

  2. To enable host-based authentication on the server, in the ssh-server-config.xml file, under the authentication-methods element, add an auth-hostbased element:

    <authentication-methods>
      <authentication action="allow">
        <auth-hostbased require-dns-match="no" />
        ...
      </authentication>
    </authentication-methods>  
    

    Also other authentication methods can be allowed.

    To force an exact match between the host name that the client sends to the server and the client's reverse mapped DNS entry, set the require-dns-match attribute to yes.

    In this case, make sure the /etc/hosts file has the fully qualified domain name listed before the short host name, 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).

    Notice that when exact DNS matching is set as required, host-based authentication through NAT (Network Address Translation) will not work.

    Using the Tectia Server Configuration tool, host-based authentication can be configured on the Authentication page. See Authentication.

  3. Run ssh-server-ctl to take the new configuration in use. See ssh-server-ctl(8).

    Click Apply to take the new settings in use.

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

$ sshg3 ServerUser@server uptime

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

===AUTO_SCHEMA_MARKUP===