Your browser does not support HTML5 local storage or you have disabled it. Some functionality on this site, including saving your privacy settings and offering you special discounts, uses local storage and may not work with local storage disabled. We recommend allowing the use of local storage in your browser. In some browsers, it is the same setting used for disabling cookies.
Host-based authentication can be enabled either by using traditional public keys or by using certificates.
Traditional Public Keys
To allow host-based authentication with traditional public keys on the server, do the following steps as ServerUser:
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.
Make sure the .shosts is owned by ServerUser and its permissions are 0600.
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:
Copy the client's /etc/ssh2/hostkey.pub 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, client.example.com 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.
In the sshd2_config file under the AllowedAuthentications keyword, add hostbased as an allowed method. For example: