“X.509 PKI”—a forbidding term; it sounds like part of a warp engine that needs calibration, right after you reinitialize the field coils. Let’s break it down: PKI stands for Public Key Infrastructure, and refers to a system for dealing in scalable fashion with the trust issues raised by deploying asymmetric (public-key) cryptography, including:

Although the term sounds generic, in practice it has come to refer specifically to hierarchical systems in which so-called Certifying Authorities (CAs) vouch for the identity of principals and certify ownership of cryptographic keys. CAs can themselves be vouched for by higher CAs, arranged in a tree of trust. This reduces the trust problem to distributing the keys of a small number of well-known authorities, avoiding the combinatorial explosion of dealing individually with every pair of principals who might need to communicate securely.

X.509 is the name of a standards document of the International Telecommunications Union (ITU, formerly the CCITT). Its original intent was to describe an authentication system for another ITU standard: X.500 directories (the title is “Recommendation X.509: The Directory Authentication Framework”). However, in the process it specified a format for digital certificates: data structures which embody the key/principal binding we mentioned, and that portion of X.509 has become widely used in PKI systems.

X.509-style PKIs also use a great many other standards. To get an idea of the scope of the subject, just take a look at the home page of the IETF PKIX working group, at:

It’s a daunting list...but we’ll just sum up the essentials here. The most important components of a certificate are:

The signature is a cryptographic function of the entire certificate data structure, and is made by the issuer using its private key (which does not appear here). The meaning of the certificate is: “the issuer vouches that the subject owns the private counterpart to this public key (but this affidavit is only good between the given validity dates).”

Now in reality, certificates can be much more complex, containing many more attributes. Also, the interpretation may be different: “owns” might mean “is authorized to use,” or “has access to sign with but does not actually know,” etc. And there are many unanswered questions here, such as how carefully did the issuer check the subject’s identity? But we’ll leave all that alone and concentrate on the basics.

The issuer and subject name are expressed as Distinguished Names (DNs), as defined by X.509. These are attribute/value sets, represented in text like this:

    /C=US/ST=New York/O=Mad Writer Enterprises/CN=Richard E. Silverman 
/emailAddress=res@oreilly.com

The attribute abbreviations here are Country, STate, Organization, and Common Name (and there are more).

Now, let’s see how all this helps with SSH host key verification.

When an SSH client connects to a server, it needs to verify that the server’s host key actually belongs to the host it intended to contact. The usual way is to compare it to a local list of already known keys, but that has many drawbacks, as we pointed out earlier. Instead of managing an unwieldy, changing set of host keys, with PKI each client needs only one public key: that of a CA shared by all hosts in the system. Each time you deploy a new Tectia host, you generate a new hostkey as usual—but you also obtain a certificate, binding the host’s name to its public key. That certificate is signed by the CA, and every client has the CA’s public key. During the key-exchange phase of the SSH protocol, the client receives the certificate along with the server’s hostkey; there are key types x509v3-sign-rsa and x509v3-sign-dss for this purpose instead of the usual ssh-rsa and ssh-dss. Instead of looking up the hostkey in a list, the Tectia client:

If the key passes all these tests, then the client considers the key valid, and server authentication succeeds. You’ll notice this doesn’t completely remove the need for key distribution: the clients do still need to get the CA key in a trusted manner. But it’s much easier to distribute or update a single key that changes very infrequently, than to manage a constantly changing known-hosts list!

Now we’ll get down to specifics with a simple example.

For our example, we’ll start with a new instance of Tectia Server installed on a Linux host; first, we need to generate a hostkey with a certificate. This is not something we can describe very comprehensively, because it relies on outside factors: what actual PKI system is in use. You might be using anything from a home-brew CA using the free OpenSSL software that comes with most Unix variants these days, to a managed PKI service outsourced to a major security vendor, involving multiple layers of hierarchy, cross-certification among organizations, separate Registration Authorities, private-key escrow, etc.

If the PKI in question uses the Certificate Management Protocols (CMP, RFC-2510), then you can use ssh-cmpclient to communicate with the PKI system: generate keys; request, receive, revoke, or update certificates; etc. You should consult your PKI vendor or managing staff as to how to proceed in this case. To keep our example simple, we’ll follow an older but still widely used process: generating a keypair and certificate request using OpenSSL, which we then supply to the CA by some simple method (email and the Web are the usual ways).

Suppose our company is Vogon Construction, Inc., and the server hostname is jeltz.vcon.com. To generate a key pair and certificate request:

    % openssl req -nodes -config -new rsa:1024 -out request.pem \
      -outform pem -keyout private.pem -days 1095 \
      -subj '/C=US/ST=New York/L=Manhattan/O=Vogon Construction, Inc./CN=jeltz.vcon.com'

This generates a new 1024-bit RSA key pair and produces two files:

The request.pem file contains the public key and asks to bind the hostname jeltz.vcon.com to that key for a period of three years (1095 days). The DN contains other information besides the hostname, and typically the CA will require set values for some of that, e.g., that the Organization field match that of the CA.

Next, send the request to the CA, and engage in whatever authentication procedures it requires: call Bob in IT, verify receipt of an email at your given address, swear an oath and sign in blood—whatever it takes. When the CA is satisfied, it will return to you a certificate, which you save in a file, certificate.blob. If it is an ASCII file looking like this:

    -----BEGIN CERTIFICATE-----
    MIIDbzCCAtigAwIBAgIDA9GvMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
    MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
    ...
    VdrJ1Z4HLT7PL+nEuvRJcpyw+A==
    -----END CERTIFICATE-----

then it is in a format called PEM; if it’s not, then it’s in another format called DER.

The two files, private.pem and certificate.blob, contain the host private key and our desired certificate; you can delete request.pem. Now, we need to convert these to Tectia’s format for host keys, in a two-step process. First:

    % openssl pkcs12 -export -out jeltz.p12 -in certificate.blob -inform {pem|der}  
-inkey private.pem

Choose “pem” or “der” depending on the format of the certificate. This stores the combined public key, private key, and certificate in a single file using yet another format, PKCS-12. You will be prompted for a passphrase to protect the file. This is a good format in which to store the keypair and certificate in case you need to rebuild the host and restore the key, so keep that file. Next:

    $ ssh-keygen -k jeltz.p12 -p ''

This will, of course, prompt you for the passphrase (twice, in fact), and finally produce the two files we want:

Now, to get Tectia sshd to use them.

Install the new key and certificate in the Tectia configuration directory:

    # install -o root -m 444 jeltz.p12-1_ssh2.crt /etc/ssh2/jeltz.crt
    # install -o root -m 444 jeltz.p12_ssh2 /etc/ssh2/jeltz

and add this to sshd2_config:

    HostCertificateFile jeltz.crt
    HostKeyFile jeltz

If you want to continue offering the existing plain ssh-dss host key as well as the new certificate, you may need to add or uncomment the following:

    PublicHostKeyFile hostkey.pub
    HostKeyFile hostkey

These are the defaults if no hostkey is specified, but once you add the HostCertificateFile, the defaults will not apply. For our example, though, we suggest you turn or leave off all other hostkeys so that successful server authentication by the client depends on this one key working.

Lastly, restart Tectia Server:

    # service sshd2 restart

and try to connect with ssh:

    % ssh jeltz.vcon.com
    warning: Received host certificate is not valid, error:
    search-state = { certificate-was-not-found database-method-search-failed } warning:
    Authentication failed.  Disconnected (local); key exchange or algorithm negotiation failed
    (Key exchange failed.).

This error message shows that we succeeded: the client received a certificate along with the host key. A debug trace will show more specifically that the host-key type has changed:

    % ssh -d4 jeltz.vcon.com
    ...
    debug: Ssh2Client/sshclient.c:244/ssh_client_key_check: Got key of type x509v3-sign-rsa
    debug: Ssh2Client/sshclient.c:286/ssh_client_key_check: Checking certificate validity
    ...

Now, we just need to arrange for the client to be able to verify the certificate.

For this, we need the CA’s public key, itself in the form of a certificate. This should be readily available from your CA; after all, the CA isn’t much use unless everyone has it. Get it in DER format; if they provide it in PEM, convert it thus:

    $ openssl x509 -inform pem -outform der -in <certificate file> -out cacert.der

Now install the CA certificate:

    # install -o root -m 444 cacert.der /etc/ssh2

configure ssh to use it:

    # /etc/ssh2/ssh2_config
    # Note 
that this 
path must be absolute, unlike in the server config, since otherwise it is relative
    # to the user's ~/.ssh2 directory.
    HostCANoCRLs /etc/ssh2/cacert.der

...and try!

    # Tectia
    $ ssh -v jeltz.vcon.com
    ...
    debug: 
Ssh2Client/sshclient.c:984/keycheck_cert_cb: 
Host certificate valid and signed by a trusted CA, accepting
    ...

If all has gone according to plan, this works, using whatever user authentication method you have available; the debug message shown indicates that the certificate validation succeeded.

We have just set up server authentication using a server-supplied certificate. In fact, the converse is possible as well: Tectia Server can authenticate users by certificate as well. As before, we need a new keypair and certificate, this time for a DN matching a user. We follow the same procedure we used earlier [11.5.1.4], but with the following subject name:

    /C=US/ST=New York/L=Manhattan/O=Vogon Construction, Inc./CN=Prostetnic V. Jeltz/ 
subjectAltName=email:pvj@vcon.com

    [ usr_cert ]

Once you have your private key and user certificate, place them in ~/.ssh2, say:

and configure ssh to use this key:

    # ~/.ssh2/identification
    CertKey pvj

We know it won’t work, since we haven’t configured the server yet—but as a test:

    % ssh -l pvj jeltz -o AllowedAuthentications=publickey
    warning: Authentication failed.
    Disconnected (local); no more authentication methods available (No 
further authentication methods available.).

We set ssh to try only public-key authentication since that’s what we want to test; this way it doesn’t end up asking for a password. The interesting message will be in the server log, typically /var/log/secure:

    sshd2: Authorization check for user pvj's certificate rejected, reason: No 
certificate authorization configured.

And now finally, we tell the server how to authorize users based on their certificates.

With the old method, there was an implicit correspondence between an account and a public key authorized to log into it: the key sat in a special file in the account’s home directory. With PKI, there is only the certificate, so we need a rule whereby Tectia can determine whether a particular certificate grants access to the requested account. In fact, Tectia allows great flexibility in expressing such rules. First, add this to the server configuration:

    # /etc/ssh2/sshd2_config
    PKI cacert.der
    PKIDisableCrls yes
    MapFile cert.users

This tells Tectia Server to trust user certificates signed by our CA, and to use the rules in /etc/ssh2/cert.users to authorize access to accounts. The rule language is described in the manpage for ssh_certd_config, section “MAPPING FILES.” We’ll give a few examples here:

    # allow a certificate issued to Prostetnic V. Jeltz in our company, access to account pvj
    #
    pvj subject C=US,ST=New York,L=Manhattan,O=Vogon Construction, Inc.,CN=Prostetnic V. Jeltz

    # allow any certificate issued to Prostetnic V. Jeltz, whether by our organization or not
    #
    pvj subject CN=Prostetnic V. Jeltz

    # allow certificate serial number 17 issued by our CA
    #
    pvj SerialAndIssuer 17 C=US,ST=New York,L=Manhattan,O=Vogon Construction, Inc.

    # allow any certificate issued by us to access account "shared"
    #
    shared Issuer C=US,ST=New York,L=Manhattan,O=Vogon Construction, Inc.

    # allow certificate with email address pvj@vcon.com
    #
    pvj email pvj@vcon.com

    # pattern rule: allow certificate with email address <foo>@vcon.com to access account <foo>
    #
    %subst% EmailRegex ([a-z]+)@vcon\.com

You would think we’d now restart sshd to have these changes take effect, but in fact Tectia has a separate daemon responsible for certificate validation: ssh-certd. So:

    # service ssh-certd restart

Now, try logging in again:

    % ssh -l pvj jeltz -o AllowedAuthentications=publickey

If all has gone well, it will work, with the following telltale message in syslog:

    sshd2: Certificate authentication for user pvj accepted.

You can have multiple PKI blocks in the server configuration, directing trust of various CAs and each with its own account mapping.

We have presented the simplest possible view of PKI; it may be much more complicated. You might interact with something called a Registration Authority for obtaining your certificate, for example, rather than directly with the CA. Verifying a certificate might involve following a chain of certificates and signatures back to a trusted “root” certificate, rather than just one—or there might be multiple trust paths, if cross-certification is available, etc.

Since it is based on symmetric cryptography, Kerberos is perforce a shared-secret system. The basic unit of Kerberos administration is called a realm, which consists of a set of principals and single KDC database they trust. When a principal joins a Kerberos realm, it shares a secret key with the KDC; the KDC database essentially consists of a list of principals and their keys. For user principals, the key is derived from a password. Principals may also correspond to software services, such as an SSH server, IMAP server, etc.; their keys are randomly generated and stored in protected files where the services can access them. A principal name looks like 1/2/3/.../ n @REALM. There can be any (positive) number of initial parts as shown, but in practice there are usually either one or two. A plain-user principal name would be res@REALM. A user principal name for particular uses, such as a privileged administrative instance, might be res/admin@REALM. And a principal representing a service—say, an IMAP server on host mail.foo.org--would have the name imap/mail.foo.org@REALM.

When principal A wants to communicate with another—say, B—principal A first tells the KDC that it wants to talk to B. Principal A needs to do two things: prove its identity to B, and establish a shared secret with B for secure communication, called a session key. The KDC provides these things in a message called a ticket, which it sends back to A. The ticket is sealed with A’s secret key, known only to the KDC and A—hence A trusts that it is genuine, and it is protected from network snooping. Unsealing the ticket, A finds the needed session key—and yet another ticket! This one, however, is sealed with B’s secret key (known only to the KDC and B). A can’t read this at all, but that doesn’t matter; all A needs to do is send this ticket as-is to B. When B unseals its ticket, it finds A’s name and another copy of the session key. Just as before, since B’s ticket is sealed with B’s key, B trusts that the ticket is genuine. The meaning of each ticket is that the KDC has shared the session key with A and B. The two principals then execute a protocol which proves to each that the other does in fact hold that key—at which point, mutual authentication is accomplished. Further, the session key can be used for subsequent security functions, such as encrypting a conversation between them.

Now, this explanation is very basic.^[152] It doesn’t exactly describe the Kerberos protocol, but rather, a simpler one. However, it gives the essential flavor of how the third-party shared-secret model works. The real Kerberos-5 protocol can be viewed as an elaboration on this basic idea, to address various possible attacks and provide more features. We won’t get any more detailed than we already have, except to list a few of the real-life differences:

Kerberos support for SSH is not defined directly; rather, there is a draft that extends SSH to use GSSAPI, as documented in “Generic Security Services/Application Programming Interface (RFC-2743).”

GSS is a sort of security meta-protocol, with a role and implementation structure similar to that of PAM or SASL. GSS allows two communicating peers to negotiate security parameters abstractly, in terms of types of protection and relative strength rather than particular protocols, ciphers, or algorithms. The GSS layers on either side will pick the strongest compatible mechanisms available to each which meet their clients’ needs, without the higher-level software needing to bother with the details. Typical GSS implementations allow adding new mechanisms in the form of system dynamic libraries, which then automatically become available to GSS clients without recompilation.

In particular, there is a GSS mechanism supporting Kerberos-5, documented in “The Kerberos Version 5 GSS-API Mechanism (RFC 1964).”

Of course, this is a bit convoluted; why not simply support Kerberos directly as its own SSH protocol extension? This was in fact done in SSH-1. The answer is that GSS is becoming a widely used standard. By defining a method for using GSS in SSH, implementers can take advantage of existing GSSAPI software libraries. And in doing so, SSH can automatically use new GSS security mechanisms as they become available, without further standards work. For example, Tectia Windows Server provides both Kerberos and NTLM user authentication via GSSAPI. The relevant SSH protocol draft is “GSSAPI Authentication and Key Exchange for the Secure Shell Protocol” (draft-ietf-secsh-gsskeyex).

Just a few years ago, this whole area was a work in progress, with only patches and experimental implementations. Now, however, it has solidified and is present in several mainstream SSH products and platforms, including OpenSSH, OS X, and Tectia on both Windows and Unix. This matches the widening adoption of Kerberos in general. And amazingly...for the most part, they all interoperate! It is now possible to have strong authentication and single-signon among various OS/SSH combinations, using Kerberos.

Note that while it has been possible for a while to get something similar using SSH public-key authentication with ssh-agent, Kerberos is a win for two different reasons. The issue of central management and scalability for larger organizations, we’ve already discussed. The other important point is that public-key authentication is SSH-specific. You go to all the trouble to teach people about generating keys, using agents, enabling agent forwarding, etc.; and after all that work, you get a solution that works only for SSH. Suppose you log into a domain account on a Windows machine, then SSH to another one. Public-key authentication may let you log in, but you’ll have to type your password again at some point to gain access to resources such as network shares—your Windows domain credentials did not follow you over SSH. With Kerberos, however, the same credentials which allowed login can also be forwarded to the remote host and used there for other purposes. And since Kerberos is a standard, the same can be true connecting from a Windows to a Unix host. This provides a much more pervasive and useful single-signon system.

As an example, we will take a lone Debian GNU/Linux box, attached to a network of Windows machines in an Active Directory domain named AD.ORG. The Linux box, lonely.ad.org, is running Debian-unstable and has the following packages installed; krb5-user, krb5-doc, and ssh-krb5 (which as of this writing is based on OpenSSH 3.8.1). The Windows machines are running the Tectia Windows Server, Version 4.2 or later. Suppose you have an account, “joe,” in the Windows domain, you’re logged into the Debian machine, and you want to connect to the Windows server, “winnie,” You simply type:

    lonely% kinit -f joe@AD.ORG

Amazingly, this prompts for your Windows password, and (assuming you type it in correctly)--it works! No errors, no complaints, no “DANGER! WARNING! WINDOWS INCOMPATIBILITY DETECTED!” Disbelievingly, you type:

    lonely% klist
    Ticket cache: FILE:/tmp/krb5cc_11500

    Default principal: joe@AD.ORG

    Valid starting     Expires            Service principal
    01/30/05 02:28:35  01/30/05 10:28:41  krbtgt/AD.ORG@AD.ORG
            renew until 01/30/05 03:28:35

You have just received Kerberos credentials from a Windows Domain Controller—say, “dc1.” No local configuration was necessary, because kinit found the domain controller via the DNS, using records like this:

    $ORIGIN ad.org
    _kerberos               TXT      "AD.ORG"
    _kerberos._udp          SRV      0 0 88  dc1
    _kerberos-master._udp   SRV      0 0 88  dc1
    _kpasswd._udp           SRV      0 0 464 dc1
    _kerberos-adm._tcp      SRV      0 0 749 dc1
    _kerberos-iv._udp       SRV      0 0 750 dc1

These tell a DNS client that machines with names under ad.org belong to the AD.ORG Kerberos realm, and that a Kerberos KDC is available on dc1.ad.org via UDP to port 88 (among other Kerberos services: some of these records might be absent or unnecessary in your DNS). The Windows DNS servers for the domain will publish such records automatically. If you have an alternate or more complicated configuration—say, using non-Windows nameservers—then you may have to add these records yourself (or you could resort to local configuration; see the manpage for krb5.conf).

Trembling with technological anticipation, you forge onward:

    lonely% ssh winnie
    The authenticity of host 'winnie (10.2.17.4)' can't be established.
    DSA key fingerprint is b6:b2:09:81:f4:c7:96:43:4a:0c:cc:12:9d:61:54:1f.
    Are you sure you want to continue connecting (yes/no)?

Remember that SSH server authentication happens first, before user authentication; this shows that we’re still using the usual SSH key-based server authentication (assuming you don’t already have winnie’s key in your known-hosts list). That’s disappointing, but we’ll talk about that later. Assuming you say yes and continue, though...

    Warning: Permanently added 'winnie,10.2.17.4' (DSA) to the list of known hosts.
    Microsoft Windows XP [Version 5.1.2600]
    (C) Copyright 1985-2001 Microsoft Corp.

    C:\Documents and Settings\joe>

You have been logged into the Windows machine! Furthermore, you’ll find that you have Windows domain credentials there; you could, for example, map a network share (via the net use command) that requires the joe identity to access—without retyping your password. Repeating the ssh command with -v will show the details:

    lonely% ssh -v winnie
    OpenSSH_3.8.1p1  Debian-krb5 3.8.1p1-7, OpenSSL 0.9.7e 25 Oct 2004
    debug1: Reading configuration data /etc/ssh/ssh_config

    debug1: Connecting to winnie [10.2.17.4] port 22.
    debug1: Connection established.
    ...
    debug1: 
 Remote protocol version 2.0, remote software version 4.2.0.21 SSH 
Secure Shell Windows NT Server
    debug1: no match: 4.2.0.21 SSH 
Secure Shell Windows NT Server
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1  Debian-krb5 3.8.1p1-7
    ...
    debug1: Authentications that can continue: gssapi-with-mic,gssapi,publickey,password
    debug1: Next authentication method: gssapi-with-mic
    debug1: Authentication succeeded (gssapi-with-mic).

The user authentication method chosen is gssapi-with-mic, an improvement which fixes a security flaw in the earlier method named simply gssapi. A subsequent klist on the client side shows the new Kerberos ticket acquired for the connection:

    lonely% klist
    Ticket cache: FILE:/tmp/krb5cc_11500
    Default principal: joe@AD.ORG

    Valid starting     Expires            Service principal
    01/30/05 02:28:35  01/30/05 10:28:41  krbtgt/AD.ORG@AD.ORG
            renew until 01/30/05 03:28:35
    01/30/05 02:45:00  01/30/05 03:45:00  host/winnie.ad.org@AD.ORG
            renew until 01/30/05 03:28:35

Now, of course, there are many possible combinations of client, server, and Kerberos systems, and some of them will require more work. For example, going the other way in this scenario (Windows to Linux) would mean joining the Debian box to the Windows Kerberos realm. You could do this using Resource Kit utilities to add its host principal, host/lonely.ad.org@AD.ORG , to the domain controller; extract a Unix-compatible keytab file from it; and copy it to /etc/krb5.keytab on the Linux machine. Or, you might solve the problem a different way by placing the non-Windows hosts in a separate realm, perhaps with Linux-based KDCs, and establishing inter-realm trust between them. These issues are more specific to Kerberos administration than to SSH proper, and are beyond our scope here.

Before leaving this case study, let’s discuss some final details of SSH configuration, server authentication, and network address translation (NAT).

SSH configuration. The Debian ssh-krb5 package is built with Kerberos authentication turned on by default; that’s not normally true. In other situations you would have to set some configuration options:

    # ~/.ssh/config
    GSSAPIAuthentication       yes
    GSSAPIDelegateCredentials  yes

You might not want to delegate credentials automatically for all connections, though, just as you might not set X forwarding on by default: it could give access to an attacker if the remote host has been compromised.

Server authentication. The secsh-keyex draft defines Kerberos server authentication as well, in the form of new SSH-TRANS key exchange methods using GSSAPI. This part of the draft is not as widely implemented as user authentication, however; for example, the Debian and OS X versions of OpenSSH support it, whereas the main OpenSSH and Tectia do not. Its use is controlled with the GSSAPIKeyExchange server keyword. To see that the client supports it, look in the -v trace for lines like this:

    debug1: Mechanism encoded as toWM5Slw5Ew8Mqkay+al2g==
    debug1: Mechanism encoded as A/vxljAEU54gt9a48EiANQ==

The “mechanisms” here are GSSAPI mechanisms, and these messages occur during the key-exchange phase.

Kerberos server authentication, when available, has several advantages:

There are some limitations, though. One is name uniqueness: hosts must have unique names known beforehand in order to be joined to the Kerberos realm. This shows up most immediately with the “localhost” problem: ssh localhost doesn’t usually work with Kerberos server authentication, even when it works for connecting to the same machine using its hostname. This is because the name “localhost” means a different host on every machine—so there can’t be an entry in the Kerberos database for “localhost,” because it can only have one key. You can make it work by arranging /etc/hosts files so that on each host, 127.0.0.1 maps back to that host’s canonical name—but the way that hosts files work, this means the name must also forward-map to the loopback address, not the host’s “real” address. This has some advantages, actually, but is likely to break some things also; it may not be worth it.

The problem can also show up with more complicated network situations such as proxies, tunnels, or clusters of machines with dynamically assigned and shared addresses—anything in which the simple server/hostname/address correspondence Kerberos needs is violated. Furthermore, it won’t work for batch jobs if those don’t also use Kerberos for authentication, which is often not the best choice. The bottom line is that while Kerberos server authentication can be useful, hostkey-based authentication usually needs to be available as well for exceptional situations.

Network address translation (NAT). Kerberos originally bound credentials to the address of the machine to which they were issued, to make attacks harder: if someone managed to steal a ticket, it would be harder to (mis)use it. However, in today’s sad world of ubiquitous NAT, this can cause more trouble than it’s worth. Most recent Kerberos deployments have this address-matching feature turned off, but you may need to do it yourself if not, e.g., with a statement like:

    # /etc/krb5.conf
    [libdefaults]
    noaddresses = true

This actually controls whether clients include addresses in ticket requests, so when you change it you will need to run kinit again. Situations involving multiple credential-forwarding connections may have addresses creep back in anyway, due to forwarding code which requests them anyway even if the original ticket had none; again, most recent Kerberos code has eliminated this problem, but you may still see it.