Is a keytab file encrypted?

Charles Hedrick hedrick at
Fri Jul 21 20:17:09 EDT 2017

You can only use the host key table from a host with the same IP address. The server verifies that the IP address corresponds to the hostname. In theory someone could bring a laptop and plug it in in place of the original host with the same IP address, but that wouldn’t let them compromise anything they couldn’t already get if they had root on the original host. We do lots of monitoring. If one of our hosts disappears, we’ll notice. If they replace it with another host at the same IP address that’s close enough to the original that we don’t  notice, it’s not clear what is being compromised. They’re just giving us free hardware...

And at least in our situation, we have various groups of systems at different security levels. So you could compromise that user on one cluster, but not system-wide. 

> On Jul 21, 2017, at 5:55:27 PM, Russ Allbery <eagle at> wrote:
> Russ Allbery <eagle at> writes:
>> Charles Hedrick <hedrick at> writes:
>>> * A kerberized service where the user registers that they want to be
>>> able to do cron jobs on a given machine.
>>> * A kerberized pam module that calls the same service and gets back
>>> credentials, locked to the IP address, and at least by default not
>>> forwardable.
>> How does this address the problem raised on this thread?  It's still the
>> case that if you become root on the host, you can just steal the keytab
>> used by that daemon and use it anywhere.  This gives you enhanced
>> protection if you trust the boundary between non-root users and root,
>> but not if you don't trust the machine.
> Oh, wait, I see -- it does transform part of the attack to occasional
> on-line, since while you can steal the system keytab and request tickets
> whenever you want, you can't get the long-lived keytab for the actual
> target credential.  (And presumably you can put monitoring and alerting
> around the host keytab being used from unexpected places.)
> Yeah, that's a partial security improvement.
> -- 
> Russ Allbery (eagle at              <>

More information about the Kerberos mailing list