To enable host-based authentication with traditional public keys on the
client, do the following as ClientUser
:
Generate a host key. If SSH 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 SSH Tectia Server is not
installed on the client host, you can create the configuration file
manually and save it in the /etc/ssh2
directory.
Add the following line in the ssh-broker-config.xml
file:
<authentication-methods> <authentication-method name="hostbased" /> ... </authentication-methods>
Also other authentication methods can be listed. Place the least interactive method first (this means usually the host-based method).
Do the following 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
server, and may require root permissions on the client as well.
SSH 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
"C:\Program Files\SSH Communications Security\SSH Tectia\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 hostname the
client is sending to the server. When the server receives the client's
public key, it forms a path based on the hostname and the key type
(ssh-dss
or ssh-rsa
) 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.
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 hostname 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 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 exact DNS matching is set as required, host-based authentication through NAT (Network Address Translation) will not work.
On Windows, using the SSH Tectia Server Configuration tool, host-based authentication can be configured on the Authentication page. See Authentication.
Run ssh-server-config-tool
to take the new
configuration in use. See ssh-server-config-tool(8).
On Windows, 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.