 |
|
Host-Based Authentication
The following terms will be used in this example: Remote
is the SSH Secure Shell server to which you are trying to
connect. RemoteUser is the user name on the server into
which you would like to login. Local is the machine
running a SSH Secure Shell client. LocalUser is the user
name on the client machine that should be allowed to login to
Remote as RemoteUser.
- First, install SSH Secure Shell on the Local and
Remote machines. Do not forget to generate a host key. If
your installation took care of this automatically, or if you
already have a copy of your
/etc/ssh2/hostkey and
/etc/ssh2/hostkey.pub, you can skip the host-key
generation. Otherwise, give the following command:
# ssh-keygen2 -P /etc/ssh2/hostkey
Note: Beginning with SSH Secure Shell version 3.0, you can
also use RSA keys.
- Copy the Local machine's
/etc/ssh2/hostkey.pub file over
to the Remote machine and name it like this:
/etc/ssh2/knownhosts/hostname.domain.ssh-dss.pub
Replace hostname.domain with the long host
name of the Local machine (the fully qualified domain
name). You will run into problems if the system does not
recognize the host name as hostname.domain.somewhere.com
but recognizes it only as hostname. You can find this out
while running sshd2 in verbose mode when trying to
establish connections.
The Remote machine now has the Local machine's public key,
so the Remote machine can verify the Local machine's identity
based on a public-key signature. By contrast,
rsh only uses the IP address for host authentication.
Note: If you use RSA keys, the name of Local's
/etc/ssh2/hostkey.pub file which is copied over to the
Remote needs to be
/etc/ssh2/knownhosts/hostname.domain.ssh-rsa.pub.
- To make sure that SSH Secure Shell finds your complete
domain name (not just the host name), edit the following line in
the
/etc/ssh2/ssh2_config file on Local:
DefaultDomain yourdomain.com
Note: The keyword mentioned in this and the following steps will only
be effective in the global ssh2_config file.
- On Remote, create a file in the home directory of
RemoteUser named
.shosts~/.shosts:
localhostname.yourdomain.com LocalUser
Be sure to chown and chmod the .shosts file. The
.shosts file must be owned by RemoteUser and should
have mode 0400.
- Check the files
/etc/ssh2/sshd2_config on Remote and
/etc/ssh2/ssh2_config on Local. Make
sure that the AllowedAuthentications field contains the
word hostbased
AllowedAuthentications hostbased,password
It does not matter what other authentication methods are
allowed. Just make sure that the hostbased keyword is
first in the list.
- Also check that
IgnoreRhosts is set to no in the
/etc/ssh2/sshd2_config file on Remote:
IgnoreRhosts no
If you had to modify the sshd2_config file, you will have to
send a HUP signal to sshd2 to make the change take effect.
# kill -HUP `cat /var/run/sshd2_22.pid`
or
# kill -HUP `cat /etc/ssh2/sshd2_22.pid`
- Now you should be all set.
On Local, log in as LocalUser and give the command
ssh RemoteUser@Remote uptime
You should now get the results of uptime run on Remote.
The first time you run ssh to that particular server, you will have to
answer yes when asked if you want to connect to the server. This is because
the local ssh does not yet have the remote server's public key. For maximum
security, it is highly recommended to verify the fingerprint of the remote
host's public key, as described in Section Public-Key Authentication to avoid man-in-the-middle attacks. This will
only be necessary when connecting for the first time.
Troubleshooting Host-Based Authentication
If you have problems with host-based authentication, check the following:
- Did you name the local host key file appropriately on Remote? It should be either
/etc/ssh2/knownhosts/HOSTNAME.ssh-dss.pub
or
/etc/ssh2/knownhosts/HOSTNAME.ssh-rsa.pub
where HOSTNAME has to be the long host name
(fully qualified domain name).
- Did you copy the host key properly?
- Check that the key on Remote is actually the same
as
hostkey.pub on Local.
On Local:
$ ssh-keygen2 -F /etc/ssh2/hostkey.pub
On Remote:
$ ssh-keygen2 -F /etc/ssh2/knownhosts/hostname.domain.ssh-dss.pub
or
$ ssh-keygen2 -F /etc/ssh2/knownhosts/hostname.domain.ssh-rsa.pub
The key fingerprints should match.
- Check your spelling in the
.shosts file.
- Make sure the
.shosts file is owned by
RemoteUser and check that its permissions are 0400.
# ls -la ~/.shosts
-r-------- 1 RemoteUser users 178 May 28 15:05 /home/RemoteUser/.shosts
- Make sure that RemoteUser's home directory on
Remote is owned by RemoteUser and is not writable
by anyone byt RemoteUser.
- Run the server and the client with the
-d3
option. This is a good way to see if a host key file is
missing, or if something is misconfigured.
Using Certificates
It is possible to use a certificate instead of the traditional
public key pair to authenticate the Local host. To use
certificates, perform the following tasks:
- Enable host-based authentication in
ssh2_config on
Local and in sshd2_config on Remote by using the
AllowedAuthentications - Define Local's server certificate in
sshd2_config
HostKeyFile <private key>
HostCertificateFile <server-certificate>
The certificate must contain a dns extension which
contains the fully qualified domain name of Local.
- Set the
DefaultDomainssh2_config - Set the
HostCALdapServerssshd2_config
on Remote.
HostCA <trusted-ca-certificate>
LdapServers ldap://server.domain:port
- Make sure that the
~/.shosts file on
Remote contains the following:
localhostname.yourdomain.com LocalUser
More information is available in the ssh-certificates man pages and
in Sections Server and
User.
Optional Additional Configuration Settings
To make the host-based authentication more secure, you may want
to consider the following optional configuration settings:
[Contents]
[Index]
[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]
Copyright © 2003 SSH Communications Security Corp.
All rights reserved.
Copyright Notice
|
|
|
