Kerberos

Realm Configuration

• <strong>Realm name</strong>: lab.bitsmasher.net
• <strong>KDC host</strong>: odroid-c1.lab.bitsmasher.net (10.10.12.254)
• <strong>KDC software</strong>: MIT Kerberos KDC running on odroid-c1
• <strong>Uptime</strong>: ~242 days (stable, rarely rebooted)

Access and Key Management

The KDC only has SSH key auth configured for the root} user. The franklin} user has been rejected by the KDC's SSH configuration -- direct root access is required for any management tasks.

Key file: /.ssh/id\_ed25519\_openclaw} (the standard openclaw key).

Principal Conventions

Kerberos principals in the lab.bitsmasher.net realm should follow these conventions:

• Service principals: \texttt{service/FQDN@lab.BITSMASHER.NET}
• User principals: \texttt{username@lab.BITSMASHER.NET}
• Host principals: \texttt{host/FQDN@lab.BITSMASHER.NET}

DNS/Kerberos Integration -- RFC Compliant (August 2026)

Kerberos relies on DNS SRV records for KDC discovery. The following records point directly to FQDN A records (no CNAME indirection):

\begin{lstlisting}[style=mystyle]

_kerberos-adm._tcp.lab.bitsmasher.net IN SRV 0 100 749 kdc1.lab.bitsmasher.net.

_kerberos._tcp.lab.bitsmasher.net IN SRV 0 0 88 kdc1.lab.bitsmasher.net.

_kerberos._udp.lab.bitsmasher.net IN SRV 0 0 88 kdc1.lab.bitsmasher.net.

_kdc._tcp.lab.bitsmasher.net IN SRV 0 0 88 kdc1.lab.bitsmasher.net.

_kdc._udp.lab.bitsmasher.net IN SRV 0 0 88 kdc1.lab.bitsmasher.net.

    \end{lstlisting}

The _kerberos-adm.\_tcp} record now points directly to the A record for kdc1.lab.bitsmasher.net}, per RFC 2782 compliance.

These records are authoritative on node3 (10.10.12.3), the new DNS master following the server1 decommissioning. If DNS is unavailable, clients fall back to manual kdc = kdc1.lab.bitsmasher.net} in /etc/krb5.conf}.

Keytab Management

Keytabs for service principals should be:

• Generated on the KDC host (odroid-c1) using \texttt{kadmin.local} or \texttt{kadmin -q}
• Transferred securely to target hosts (via scp with SSH keys)
• Set to mode 600 and owned by the appropriate service user

<strong>Note</strong>: Kerberos keytabs have not been deployed across the infrastructure. NFS exports with sec=krb5i} are currently non-functional pending keytab deployment. The Ansible ssh role handles the StrictModes requirements for SSH-based keytab transfer.