Authentication: Verifying Identities

A large part of the SSH server’s job is to grant or deny connection requests from clients. This is done at two levels: authentication and access control (a.k.a. authorization). We discuss the former here and the latter in the section "Access Control: Letting People In.” [5.5] Authentication, as we’ve seen, means verifying the identity of the user requesting a connection.

5.4.1 Authentication Syntax

sshd supports several different techniques for authentication that may be enabled or disabled. [3.1.3] [3.4.3] For example, if you don’t trust password authentication, you can turn it off serverwide but still permit public-key authentication.

As SSH has evolved, the syntax for configuring authentication has changed several times, and OpenSSH and Tectia use entirely different syntaxes. In OpenSSH, different authentication techniques are turned on and off with keywords of the form:

<Name_Of_Technique>Authentication

For example, password authentication is controlled by the keyword PasswordAuthentication, public-key authentication by PubKeyAuthentication, and so forth, one keyword per technique. Values may be yes or no, as in:

    # OpenSSH
    PubKeyAuthentication yes

Table 5-1 lists all the authentication techniques supported by OpenSSH, and each is described in detail later.

Table 5-1. OpenSSH authentication keywords

Keyword	Meaning
`ChallengeResponseAuthentication`	One-time passwords.
`GSSAPIAuthentication`	Typically used for Kerberos.
`HostbasedAuthentication`	Host-based authentication.
`PasswordAuthentication`	Password authentication. Exactly what this means is determined by the `UsePAM` and `KerberosAuthentication` keywords.
`PubKeyAuthentication`	Public-key authentication.
`RhostsRSAAuthentication`	SSH-1 protocol only: avoid.
`RSAAuthentication`	SSH-1 protocol only: avoid.

Tectia has a more extensible syntax. Instead of creating a new keyword for each technique, you use only two keywords, AllowedAuthentications and RequiredAuthentications. Each is followed by the names of one or more authentication techniques, separated by commas. For example:

    # Tectia
    AllowedAuthentications password,hostbased,publickey

AllowedAuthentications means that any of the given techniques can be used. In contrast, RequiredAuthentications means that all of the listed techniques must be used. If both keywords are present, then RequiredAuthentications is used, and AllowedAuthentications is ignored.^[62] Table 5-2 lists the supported values for these keywords. The first four techniques are specified by the IETF SECSH draft, while the ones with the @ssh.com suffix are nonstandard. It doesn’t matter in what order you list the values because the SSH client, not the server, drives the authentication process. By default, Tectia’s sshd allows only password and public-key authentication.

Table 5-2. Tectia authentication techniques for AllowedAuthentications and RequiredAuthentications

Value	Meaning
`password`	Password authentication.
`publickey`	Public-key authentication.
`hostbased`	Host-based authentication.
`keyboard-interactive`	Extensible, general-purpose, interactive authentication.
`gssapi-with-mic`	GSSAPI authentication with Message Integrity Code (MIC).
`gssapi`	GSSAPI authentication (deprecated in favor of `gssapi-with-mic`).
`kerberos-2@ssh.com`	Kerberos. Unsupported. Not available by default: requires recompilation.
`kerberos-tgt-2@ssh.com`	Kerberos authentication with TGT (passed to server). Unsupported. Not available by default: requires recompilation.
`pam-1@ssh.com`	Mostly obsolete: replaced by `keyboard-interactive`. Used only for old clients.
`securid-1@ssh.com`	Mostly obsolete: replaced by `keyboard-interactive`. Used only for old clients.

We now describe how to enable and disable each type of authentication except the deprecated SSH-1 keywords, which are in Appendix D.

5.4.2 Password Authentication

Password authentication accepts your login password as proof of identity. [3.4.3.5] OpenSSH allows or disallows password authentication with the PasswordAuthentication keyword, given the value yes (the default) or no:

    # OpenSSH
    PasswordAuthentication yes

Normally, OpenSSH password authentication requires your ordinary login password. However, this may be changed via PAM [5.4.8], Kerberos [5.4.7], or other features.

For Tectia, you can allow or require password authentication by adding the value password to the lists for AllowedAuthentications or RequiredAuthentications, respectively:

    # Tectia
    AllowedAuthentications password

5.4.2.1 Failed password attempts

Tectia servers wait two seconds by default after each failed password authentication attempt, to thwart brute-force password-guessing attacks. The AuthInteractiveFailureTimeout keyword controls this delay:

    # Tectia
    AuthInteractiveFailureTimeout 5

5.4.2.2 Empty passwords

If an account has an empty password, both the OpenSSH and Tectia servers may refuse access to the account. This feature is controlled by the keyword PermitEmptyPasswords with a value of yes (the default) or no. If enabled:

    PermitEmptyPasswords yes

empty passwords are permissible; otherwise, they are not.

5.4.2.3 Expired passwords

Some operating systems support expiration dates for passwords. For those that do, OpenSSH and Tectia allow expired passwords to be changed during authentication.

If the OpenSSH server detects an expired password, it runs the system passwd command to change it once the user has logged in. It then closes the connection so that the user must log in again:

    $ ssh -oPubKeyAuthentication=no -l smith server.example.com
    smith@server.example.com's password:
    Last login: Sat Jan 22 17:07:27 2005 from client.example.com
    WARNING: Your password has expired.
    You must change your password now and login again!
    Changing local password for smith.
    Old password:
    New password:
    Retype new password:
    Connection to server.example.com closed.

For Tectia, by default, after the server verifies the user’s password, if the password is found to be expired, then the system’s password-change program (e.g., passwd) is run as a forced command. [8.2.3] An alternate password-change program (e.g., one that enforces policies for choosing good passwords) can be specified by the PasswdPath keyword:

    # Tectia
    PasswdPath /usr/local/bin/goodpasswd

The password-change program runs with the privileges of the user, not those of the server (typically root). Here’s an example of a password change during authentication, from the client’s perspective:

    $ ssh server.example.com
    rebecca's password: < ... old, expired password ... >
    Authentication successful.
    < ... the following output is from running the passwd forced command ... >
    Changing password for user rebecca.
    Changing password for rebecca
    (current) UNIX password: < ... old, expired password, again ... >
    New password: < ... new password ... >
    Retype new password: < ... new password, again ... >
    passwd: all authentication tokens updated successfully.
    Connection to server.example.com closed.

We discuss more powerful alternatives to this technique in a later case study. [11.7.1]

5.4.3 Public-Key Authentication

Public-key authentication verifies a user’s identity by cryptographic key. [2.4] In OpenSSH, public-key authentication is permitted or forbidden with the PubKeyAuthentication keyword which may have the value yes (the default) or no:^[63]

    #  OpenSSH
    PubKeyAuthentication yes

For Tectia, you allow or require public-key authentication by adding the value publickey to the lists for AllowedAuthentications or RequiredAuthentications, respectively:

    # Tectia
    AllowedAuthentications publickey

Tectia provides keywords that restrict the minimum and maximum sizes for public keys:

    # Tectia
    AuthPublicKey.MinSize 1024
    AuthPublicKey.MaxSize 2048

You might want to require a minimum key size for improved security, but reject huge keys because they slow down authentication. A value of zero (the default) disables the key-size checks.

Public-key authentication is marvelously configurable for most SSH implementations. See Chapter 8 for details on tailoring authentication for individual accounts.

5.4.4 Hostbased Authentication

Hostbased authentication verifies an SSH client’s identity by checking the remote hostname and username associated with it. [3.4.3.6] This mimics the behavior of the insecure Berkeley r-commands (rsh, rlogin, rcp) which check the server files /etc/hosts.equiv and ~/.rhosts for permission to authenticate. SSH’s hostbased authentication is more secure, however: instead of relying on a potentially compromised network naming service (e.g., DNS, NIS) and a privileged TCP source port, the SSH server uses secure, cryptographic tests of host keys to verify the client host’s identity.

OpenSSH has the keyword HostbasedAuthentication (surprise!) to enable or disable this type of authentication:^[64]

    #  OpenSSH
    HostbasedAuthentication yes

For Tectia, you allow or require hostbased authentication by adding the value hostbased to the lists for AllowedAuthentications or RequiredAuthentications, respectively:

    # Tectia
    AllowedAuthentications hostbased

Hostbased authentication is useful but unfortunately also enables connections via the insecure r-commands, since it obeys the same permission files. To eliminate this potential security risk, use the SSH-specific files /etc/shosts.equiv and ~/.shosts instead of /etc/hosts.equiv and ~/.rhosts. In fact, we recommend you delete /etc/hosts.equiv and forbid your users to create ~/.rhosts files. (An even better approach is to disable the services for insecure protocols like the r-commands; these services are usually started by inetd or xinetd.)

You can also tell the SSH server to ignore all users’ .rhosts and .shosts files with the keyword IgnoreRhosts. (This keyword does not impact the system files /etc/shosts.equiv and /etc/hosts.equiv, however.) Permissible values are yes (to ignore them) or no (the default):

    IgnoreRhosts yes

Ignoring users’ files might be appropriate in an environment of centralized control, where only sysadmins are authorized to decide which hosts are trusted for authentication.

Tectia permits separate control over hostbased authentication for root. The keyword IgnoreRootRhosts permits or prevents use of the superuser’s .rhosts and .shosts files, overriding IgnoreRhosts:

    # Tectia
    IgnoreRootRhosts yes

Values of yes (ignore the files) and no (don’t ignore) are permitted. If not specified, the value of IgnoreRootRhosts defaults to that of IgnoreRhosts. For example, you can permit all .rhosts and .shosts files except root’s:

    # Tectia
    IgnoreRhosts no
    IgnoreRootRhosts yes

or ignore all .rhosts files except root’s:

    # Tectia
    IgnoreRhosts yes
    IgnoreRootRhosts no

Again, IgnoreRootRhosts doesn’t stop the server from considering /etc/hosts.equiv and /etc/shosts.equiv. For stronger security, it’s best to disable hostbased access entirely.

The SSH server needs the public keys of all hosts from which it accepts connections via hostbased authentication. These keys are kept in a single file, /etc/ssh/ssh_known_hosts (for OpenSSH), or in separate files in the directory /etc/ssh2/knownhosts (for Tectia). A host’s public key is fetched from these locations whenever that host requests a connection. Optionally, the server also searches the file ~/.ssh/known_hosts (for OpenSSH) or separate files in the directory ~/.ssh2/knownhosts in the target user’s account.

This optional feature (which is enabled by default) can be controlled with the keywords IgnoreUserKnownHosts (for OpenSSH):

    # OpenSSH
    IgnoreUserKnownHosts yes

or UserKnownHosts (for Tectia):

    # Tectia
    UserKnownHosts no

Having sshd consult the user’s known hosts database might be unacceptable in a security-conscious environment. Since hostbased authentication relies on the integrity and correct administration of the client host, the system administrator usually grants hostbased authentication privileges to only a limited set of audited hosts. If the user’s file is respected, however, a user can extend this trust to a possibly insecure remote host. An attacker can then:

Compromise the insecure, remote host
Impersonate the user on the remote host
Access the user’s local account via SSH, without needing a key passphrase or the local account password

Hostbased authentication can be complicated by other aspects of your server machine’s environment, such as DNS, NIS, and the ordering of entries in static host files. It may also open new avenues for attack on a system. [3.4.3.6]

Tectia servers can re quire that the hostname provided by the client must match the one found in DNS, using the keyword HostbasedAuthForceClientHostnameDNSMatch:

    # Tectia
    HostbasedAuthForceClientHostnameDNSMatch yes

By default, no such check is performed, and in practice, this feature provides only a moderate level of protection against spoofing, since the DNS server(s) can still be attacked. [3.6.2]

5.4.5 Keyboard-Interactive Authentication

Keyboard-interactive authentication is an extensible, general-purpose mechanism for implementing a variety of authentication techniques that require interaction with the remote user, such as one-time passwords and challenge-response schemes. Clients must implement the keyboard-interactive protocol (described in an IETF SECSH draft, and tunneled securely over the SSH transport layer) but need no other modifications as new authentication techniques are added.

An example of a keyboard-interactive authentication technique is one-time passwords, found in systems like Bellcore’s S/Key. “One-time” means that each time you authenticate, you provide a different password, helping to guard against attacks, since a captured password will likely be useless. Here’s how it works:

When you connect to a remote service, it provides you with an integer and a string, called the sequence number and the key, respectively.
You enter the sequence number and key into an S/Key calculator program on your local machine.
You also enter a secret passphrase into the calculator, known only to yourself. This passphrase isn’t transmitted over the network, only into the calculator on your local machine, so security is maintained.
Based on the three inputs you provided, the calculator produces your one-time password.
You enter the password to authenticate to the remote service.

More information on one-time passwords is available at:

http://www.ietf.org/html.charters/otp-charter.html

5.4.5.1 OpenSSH keyboard-interactive authentication

In OpenSSH, you enable keyboard-interactive authentication with the keyword ChallengeResponseAuthentication:

    # sshd_config
    ChallengeResponseAuthentication yes

OpenSSH supports three challenge/response methods, called “devices,” listed in Table 5-3. Since these methods are dependent on external software, you have to configure OpenSSH at compile time to support them.

Table 5-3. OpenSSH keyboard-interactive (challenge/response) authentication methods

Method	Device name	Compilation option
BSD authentication	`bsdauth`	--with-bsd-auth
PAM	`pam`	--with-pam
S/Key	`skey`	--with-skey

PAM is widely available and hence often included in compiled OpenSSH packages. Just make sure the server configuration keyword UsePAM is set: [5.4.8]

    # OpenSSH
    UsePAM yes

BSD authentication will likely be available only if running on a BSD platform (e.g., OpenBSD); see the manpage for login.conf for details on its operation. If you want S/Key support, you have two options: obtain a PAM library that supports it, such as libpam_opie or libpam_skey, or build OpenSSH yourself to get direct S/Key support. We recommend the PAM library approach.

In conducting keyboard-interactive authentication, the client by default specifies no device, which means the server will try all. There’s an undocumented client-side option, KbdInteractiveDevices, however, whose value is the list of devices to try:

    # OpenSSH
    KbdInteractiveDevices pam,skey,bsdauth

5.4.5.2 Tectia’s keyboard-interactive authentication

For Tectia, you can allow or require keyboard-interactive authentication by adding the value keyboard-interactive to the lists for AllowedAuthentications or RequiredAuthentications, respectively:

    # Tectia
    AllowedAuthentications keyboard-interactive

Tectia servers support the following keyboard-interactive authentication techniques:

password: Standard password authentication [5.4.2]
pam: Pluggable Authentication Modules [5.4.8]
securid: SecurID hardware-based authentication
plugin: Programmatic authentication [11.7.2]

Keyboard-interactive authentication techniques can be either optional or required (or both), and are specified using the keywords AuthKbdInt.Optional or AuthKbdInt.Required. Multiple authentication techniques are separated by commas:

    # Tectia
    AuthKbdInt.Optional pam,securid,password
    AuthKbdInt.Required plugin,password

The order of the authentication techniques is not significant for either keyword, since the client drives the authentication process.

Warning

Beware of typographic errors in the values of AuthKbdInt.Optional and AuthKbdInt.Required: they are not checked when the server reads them from configuration files. Invalid or unrecognized techniques are detected only when keyboard-interactive authentication is attempted, which can be long after the server starts.

Authentication succeeds if all of the required authentication techniques succeed, as well as a number of optional authentication techniques specified by the AuthKbdInt.NumOptional keyword:

    # Tectia
    AuthKbdInt.NumOptional 2

The default for AuthKbdInt.NumOptional is zero if there are any required authentication techniques, or one otherwise.

The AuthKbdInt.Retries keyword determines how many attempts are allowed for keyboard-interactive authentication:

    # Tectia
    AuthKbdInt.Retries 5

By default, three retries are allowed.

The Tectia server waits after each failed keyword-interactive authentication attempt, as for password authentication; the AuthInteractiveFailureTimeout keyword applies to this delay. [5.4.2.1]

The keyboard-interactive password authentication technique is functionally identical to standard password authentication. [5.4.2]

PAM authentication is supported by binary distributions of Tectia on systems that provide PAM (e.g., Linux, Solaris). On other systems, support for PAM requires recompiling the SSH server with the appropriate PAM headers and libraries. [5.4.8]

SecurID from Security Dynamics is a hardware-based authentication technique. Users need a physical card, called a SecurID card, in order to authenticate. The card contains a microchip that displays (on a little LCD) an integer that changes at regular intervals. To authenticate, provide this integer along with your password. Some versions of the SecurID card also have a keypad that supports entering a password, for two-factor authentication. Users must provide the current integer from their card in order to authenticate.

By default, Tectia allows three attempts to enter the SecurID password. This can be changed with the SecurIdGuesses keyword:

    # Tectia
    SecurIdGuesses 5

SecurID support is included in binary distributions of Tectia. The securid keyboard-interactive authentication technique mentioned previously refers to code incorporated into the server. Alternately, separate plugins called ssh-securidv5-plugin and ssh-securidv4-plugin are provided for different RSA ACE versions on some platforms.^[65] In either case, recompiling the server or plugins requires special SecurID headers and libraries. SecurID must also be configured by setting the environment variable VAR_ACE to the pathname of the ACE data directory before the server is started: consult the SecurID documentation for details.

New authentication techniques can be added using keyboard-interactive plugins. If plugin is specified as either an optional or required keyboard-interactive authentication technique, then the AuthKbdInt.Plugin keyword must be used to identify a program that controls the interactive authentication steps:^[66]

    # Tectia
    AuthKbdInt.Plugin /usr/local/sbin/ssh-keyboard-interactive-plugin

The server communicates with the plugin program using the Tectia plugin protocol, which we’ll describe in a later case study. [11.7.2]

5.4.6 PGP Authentication

Tectia can authenticate users via the PGP key. We cover this topic in Chapter 6. [6.5]

5.4.7 Kerberos Authentication

Kerberos, the well-known secure authentication system, can be used by OpenSSH and Tectia. We summarize the Kerberos-related configuration keywords here and defer a more detailed treatment of the topic. [11.4]

5.4.7.1 Kerberos and OpenSSH

Kerberos authentication is supported only if enabled at compile time by the configuration option --with-kerberos5. Assuming the SSH server was built in this manner, Kerberos authentication can be used in two ways: directly, and as a verifier for password authentication.

Direct Kerberos authentication is enabled by the GSSAPIAuthentication keyword:

    # OpenSSH
    GSSAPIAuthentication yes

This allows normal, ticket-based Kerberos user authentication: it requires that the usual service principal host/server@REALM be added to the Kerberos KDC, and that principal’s key added to the server host keytab, usually /etc/krb5.keytab. By default, the Kerberos principal foo@REALM will be allowed access to server account “foo”; you can allow others by adding them to ~foo/.k5login (along with foo@REALM itself, which would otherwise lose access!). There is also the default:

    # OpenSSH
    GSSAPICleanupCredentials yes

which means sshd will delete a user’s forwarded Kerberos credentials on logout; this is usually a good idea and should be left on. [11.5.2]

The second method, password verification, is indirect. It does not require any Kerberos support on the client at all: it simply means that for regular SSH password authentication, sshd will verify a user’s password against Kerberos. This mode is enabled or disabled by the keyword KerberosAuthentication with the value yes or no:

    # OpenSSH
    KerberosAuthentication yes

Instead of checking against the local login password, sshd requests a Kerberos ticket-granting ticket (TGT) for the user and allows login if the ticket matches the password.^[67] It also stores that TGT in the user’s credentials cache, eliminating the need to do a separate kinit. Note that for technical reasons, the server also requires a service principal in this case, even though it might not seem necessary: there’s an extra step involved that protects against a KDC spoofing attack.

If Kerberos fails to validate a password, the server optionally validates the same password by ordinary password authentication. This is convenient in an environment where not everyone uses Kerberos. To enable this option, use the keyword KerberosOrLocalPasswd with a value of yes; the default is no:

    # OpenSSH
    KerberosOrLocalPasswd yes

Finally, since password authentication via Kerberos may also result in stored Kerberos user credentials, there’s a KerberosTicketCleanup keyword:

    # OpenSSH
    KerberosTicketCleanup yes

Similar to GSSAPICleanupCredentials, this has the server delete such credentials upon logout.

OpenSSH also used to support Kerberos TGT passing via the KerberosTgtPassing keyword, but at press time the support has been removed.

5.4.7.2 Kerberos and Tectia

Kerberos is used with Tectia via GSSAPI authentication. You can allow or require GSSAPI authentication by adding the value gssapi to the lists for AllowedAuthentications or RequiredAuthentications, respectively:

    # Tectia
    AllowedAuthentications gssapi

Tip

GSSAPI authentication was added in Tectia Version 4.2. The older kerberos-2@ssh.com and kerberos-tgt-2@ssh.com authentication methods are still available if they were enabled when Tectia was configured, but they are unsupported.

The GSSAPI.AllowedMethods keyword specifies a list of allowed GSSAPI methods. Currently, only kerberos is supported:

    # Tectia
    GSSAPI.AllowedMethods kerberos

The kerberos GSSAPI method is allowed by default, so there is currently no reason to use the GSSAPI.AllowedMethods keyword, unless you want to be explicit.

Tectia’s GSSAPI authentication attempts to use the MIC. If the keyword GSSAPI.AllowOldMethodWhichIsInsecure is enabled, then Tectia is willing to fall back to using GSSAPI without MIC:

    # Tectia
    GSSAPI.AllowOldMethodWhichIsInsecure yes

The default is yes, since GSSAPI with MIC is not yet widely supported. If the value no is used, then GSSAPI authentication requires MIC: another way to specify this is to use gssapi-with-mic instead of gssapi as the authentication method.

The GSSAPI.Dlls keyword identifies the location of the GSSAPI libraries, as a comma-separated list of full pathnames:

    # Tectia
    GSSAPI.Dlls /usr/local/gssapi/lib/libgssapi.so

By default, Tectia searches a list of common locations for the libraries, including:

/usr/lib/libgssapi_krb5.so
/usr/lib/libkrb5.so
/usr/lib/libgss.so
/usr/local/gss/gl/mech_krb5.so
/usr/local/lib/libgssapi_krb5.so
/usr/local/lib/libkrb5.so
/usr/kerberos/lib/libgssapi_krb5.so
/usr/kerberos/lib/libkrb5.so
/usr/lib/gss/libgssapi_krb5.so

The .so suffix varies for different Unix platforms.

5.4.8 PAM Authentication

The Pluggable Authentication Modules system (PAM) by Sun Microsystems is an infrastructure for supporting multiple authentication methods; it’s found on Solaris and most Linux systems. Ordinarily when a new authentication mechanism comes along, programs need to be rewritten to accommodate it. PAM eliminates this hassle. Programs are written to support PAM, and new authentication mechanisms may be plugged in at runtime without further source-code modification. More PAM information is found at:

http://www.sun.com/software/solaris/pam/

OpenSSH includes support for PAM, enabled with the UsePAM keyword, which defaults to no:

    # OpenSSH
    UsePAM yes

Tectia supports PAM as a keyboard-interactive authentication technique. [5.4.5]

5.4.9 Privilege Separation

OpenSSH supports privilege separation, a security feature that isolates the code that requires root privileges. [3.6.5] You can enable and disable it with the keyword UsePrivilegeSeparation with the value yes (the default) or no.

    # OpenSSH
    UsePrivilegeSeparation yes

5.4.10 Selecting a Login Program

Most Unix systems have a program called login for setting up a new user login process. It can be called by the getty process, for instance, when processing logins on a terminal line, or by a Telnet server. By default, OpenSSH does not use the system’s login program. You can make it do so with the UseLogin keyword:

    # OpenSSH
    UseLogin yes

You might need to do this if your system has a login program that performs some specialized processing missing from OpenSSH. However, there are drawbacks to UseLogin yes:

X forwarding is turned off, since sshd loses the chance to specially handle its xauth cookies for X authentication.
Privilege separation is turned off after user authentication, in order to allow login to function correctly.

The behavior of a login program versus a login shell is entirely implementation- and operating-system-specific, so we won’t cover the intricacies. If you need to muck about with UseLogin, you first need to understand the features of your operating system and your login program in detail.

^[62]This behavior, with RequiredAuthentications overriding AllowedAuthentications, began in Version 3.1.0 of Tectia’s sshd. In previous versions, the two keywords were used together, but in practice this forced the two lists of techniques to be identical: a required technique must also be allowed, and an allowed technique that is not required is pointless, since it would be insufficient for authentication.

^[63]For SSH-1 protocol connections in OpenSSH, use the keyword RSAAuthentication instead.

^[64]OpenSSH has another keyword, RhostsRSAAuthentication, that applies only to SSH-1 protocol connections.

^[65]If SecurID plugins are used, specify plugin instead of securid as the value of AuthKbdInt.Optional or AuthKbdInt.Required, and set AuthKbdInt.Plugin to the pathname for the appropriate plugin.

^[66]If no plugin program is specified, or the specified program cannot be run, then keyboard-interactive plugin authentication will always fail.

^[67]It also requires a successful granting of a host ticket for the local host as an antispoofing measure.

Previous Chapter

Getting Ready: Initial Setup

Next Chapter

Access Control: Letting People In