Access networking home directory securely and SSH protocol transition feature

abbra commented

2026-03-11 08:34:21 +00:00

Member

When your home directory is placed on a networking file system, you want to obtain Kerberos ticket to authenticate against your NFS or SMB server in order to mount your home directory. In a normal setup, a login over SSH protocol does not delegate user's Kerberos ticket at all: it is insecure to delegate the initial ticket granting ticket (TGT) and even disabled in Active Directory for cross-domain trust setup. If you'd use password-based SSH login, SSSD or Winbind on the target SSH server will generate the Kerberos TGT. However, for all other methods (public key authentication, smartcard authentication, Kerberos without delegation, ...) such ticket would not be created.

Kerberos deployments such as Active Directory and FreeIPA allow applications to operate on behalf of users (Kerberos principals). Originally this came as an Active Directory extension documented in MS-SFU specification. MS-SFU ("services for users", S4U) defines two modes of operation:

protocol transition (S4U2Self), where an application does authenticate a user through a non-Kerberos mechanism and asks a KDC to issue a ticket to itself (thus, S4U2Self name). This operation is always allowed: the application's service has access to its own Kerberos key and can always print such ticket itself anyway. This is the operation every Windows machine is used when user logs in to obtain logon information detail (group membership, home directory, etc.).
operation on behalf of a user against a different Kerberos service: given S4U2Self evidence ticket, ask KDC to issue a ticket to a different backend service on behalf of the user (proxy user's request, thus S4U2Proxy). This operation is tightly controlled: KDCs perform check of special access controls. There are two types of access controls: constrained delegation rules and resource-based constrained delegation (RBCD) rules. They lead to the same result: if the request of the "proxy" service is allowed to delegate user's operation to the "target" service, then S4U2Proxy ticket is issued and can be used.

Thus, there are two important stepping stones to solve the original networking home directory mounting problem:

An application used for login (OpenSSH server) needs to implement protocol transition from its supported authentication mechanisms to Kerberos.
Kerberos deployment needs to provide a way to safely configure permissions to allow hosts to request proxy tickets towards NFS or SMB servers.

First issue is being solved through introduction of S4U operations to OpenSSH. It is currently in development and can be tested through the following COPR repository:

COPR repo for Fedora 43-45: dnf copr enable dbelyavs/openssh-gss-s4u

Two demos are provided:

Demo 1: login with SSH key, use Kerberos ticket for sudo authentication. Lifetime set to 1 minute to help with the demo.

https://youtu.be/hlxFCs_RIRE

Demo 2: login with SSH key, use Kerberos ticket for access of FreeIPA management interface. Lifetime was set to 2 minutes to help my slow and errorneous typing.

https://youtu.be/Bx7_ZJskofo

Second issue is partially solved for both Active Directory and FreeIPA. In Active Directory resource-based constrained delegation allows NFS/SMB server service owner to grant permissions based on the SIDs present in the login token of of the requestor service (machine). It means machine accounts can be allowed to delegate user Kerberos tickets to NFS servers. In FreeIPA this problem is solved partially: there is a way to add such permissions but every single machine principal (host/machine.name.tld) needs to be explicitly mentioned. A support for 'all machines' or a 'subset of machines' needs to be added to FreeIPA.

S4U2Self operation gives a Kerberos ticket that can also be consumed directly by other applications which have access to the host keytab. For example, pam_sss_gss.so PAM module (configured via authselect enable-feature with-gssapi in SSSD profile) accepts S4U2Self ticket for authentication. This is demonstrated in Demo 1 above.

For local KDC the same infrastructure will be reused. Local KDC does not yet provide RBCD implementation, thus it needs to be added. At least for S4U2Self operation Local KDC should already work and can be made default for Fedora 45.

When your home directory is placed on a networking file system, you want to obtain Kerberos ticket to authenticate against your NFS or SMB server in order to mount your home directory. In a normal setup, a login over SSH protocol does not delegate user's Kerberos ticket at all: it is insecure to delegate the initial ticket granting ticket (TGT) and even disabled in Active Directory for cross-domain trust setup. If you'd use password-based SSH login, SSSD or Winbind on the target SSH server will generate the Kerberos TGT. However, for all other methods (public key authentication, smartcard authentication, Kerberos without delegation, ...) such ticket would not be created. Kerberos deployments such as Active Directory and FreeIPA allow applications to operate on behalf of users (Kerberos principals). Originally this came as an Active Directory extension documented in [MS-SFU specification](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/). MS-SFU ("services for users", S4U) defines two modes of operation: - protocol transition (S4U2Self), where an application does authenticate a user through a non-Kerberos mechanism and asks a KDC to issue a ticket to itself (thus, S4U2Self name). This operation is always allowed: the application's service has access to its own Kerberos key and can always print such ticket itself anyway. This is the operation every Windows machine is used when user logs in to obtain logon information detail (group membership, home directory, etc.). - operation on behalf of a user against a different Kerberos service: given S4U2Self evidence ticket, ask KDC to issue a ticket to a different backend service on behalf of the user (proxy user's request, thus S4U2Proxy). This operation is tightly controlled: KDCs perform check of special access controls. There are two types of access controls: constrained delegation rules and resource-based constrained delegation (RBCD) rules. They lead to the same result: if the request of the "proxy" service is allowed to delegate user's operation to the "target" service, then S4U2Proxy ticket is issued and can be used. Thus, there are two important stepping stones to solve the original networking home directory mounting problem: 1. An application used for login (OpenSSH server) needs to implement protocol transition from its supported authentication mechanisms to Kerberos. 2. Kerberos deployment needs to provide a way to safely configure permissions to allow hosts to request proxy tickets towards NFS or SMB servers. First issue is being solved through introduction of S4U operations to OpenSSH. It is currently in development and can be tested through the following COPR repository: COPR repo for Fedora 43-45: `dnf copr enable dbelyavs/openssh-gss-s4u ` Two demos are provided: 1. Demo 1: login with SSH key, use Kerberos ticket for sudo authentication. Lifetime set to 1 minute to help with the demo. https://youtu.be/hlxFCs_RIRE 2. Demo 2: login with SSH key, use Kerberos ticket for access of FreeIPA management interface. Lifetime was set to 2 minutes to help my slow and errorneous typing. https://youtu.be/Bx7_ZJskofo Second issue is partially solved for both Active Directory and FreeIPA. In Active Directory resource-based constrained delegation allows NFS/SMB server service owner to grant permissions based on the SIDs present in the login token of of the requestor service (machine). It means machine accounts can be allowed to delegate user Kerberos tickets to NFS servers. In FreeIPA this problem is solved partially: there is a way to add such permissions but every single machine principal (`host/machine.name.tld`) needs to be explicitly mentioned. A support for 'all machines' or a 'subset of machines' needs to be added to FreeIPA. S4U2Self operation gives a Kerberos ticket that can also be consumed directly by other applications which have access to the host keytab. For example, `pam_sss_gss.so` PAM module (configured via `authselect enable-feature with-gssapi` in SSSD profile) accepts S4U2Self ticket for authentication. This is demonstrated in Demo 1 above. For local KDC the same infrastructure will be reused. Local KDC does not yet provide RBCD implementation, thus it needs to be added. At least for S4U2Self operation Local KDC should already work and can be made default for Fedora 45.

abbra added this to the Integrating LocalKDC project

2026-03-11 08:34:22 +00:00

abbra commented

2026-03-11 08:37:22 +00:00

Author

Member

Implement OpenSSH protocol transition feature and make it available in Fedora
Implement service group and maybe wildcard RBCD permissions in FreeIPA
Implement RBCD support in Local KDC
Integrate protocol transition as a base feature of Local KDC

- [x] Implement OpenSSH protocol transition feature and make it available in Fedora - [ ] Implement service group and maybe wildcard RBCD permissions in FreeIPA - [ ] Implement RBCD support in Local KDC - [x] Integrate protocol transition as a base feature of Local KDC

pboy added the

meeting

ongoing work project

labels

2026-03-16 16:16:29 +00:00

abbra was assigned by pboy

2026-03-16 16:16:44 +00:00

abbra commented

2026-03-18 17:54:07 +00:00

Author

Member

I'm attaching FreeIPA-specific demo document explaining how I created those videos.

openssh-s4u-freeipa.md

15 KiB

dbelyavs commented

2026-03-19 12:29:35 +00:00

I've landed these patches in rawhide, NVR is openssh-10.2p1-7.fc45

abbra commented

2026-03-28 20:42:36 +00:00

Author

Member

I have built a test version of Local KDC in COPR abbra/krb5-test.

Quick setup

To test you need Fedora Rawhide (there is a build for Fedora 44 as well):

# dnf copr enable abbra/krb5-test
# dnf install localkdc{,-kdb,-pam-auth,-selinux}

Optionally install Samba:

# dnf install samba samba-client

In order to setup local KDC, run localkdc-setup command:

# localkdc-setup

You'll get a deployment where local KDC is activated on demand whenever a Kerberos client such as kinit connects to the UNIX domain socket /run/localkdc/kdc.sock. All configuration is predefined, including Kerberos services for this host. The configuration is a bit opinionated: it sets up use of SSSD with localkdc domain that uses proxy ID provider pointing to /etc/passwd + /etc/group and authentication provider using Kerberos (krb5). It also configures PAM stack to allow pam_sss_gss module and permits use of Kerberos tickets for sudo and sudo -i authentication.

User authentication

None of the Kerberos principals for user accounts are there. This is intentional.

If you create user accounts with useradd <username> && passwd <username> then the local KDC will be able to see the accounts through systemd's userdb interface and will be able to authenticate them using their passwords via PAM service system-auth.

This flow is organized through the use of Kerberos OTP pre-authentication mechanism. As a result, you will see an OTP prompt when performing kinit <username>. A special localkdc-pam-auth helper will be triggered by the local KDC and will perform this authentication. After successful PAM authentication, local KDC will issue a Kerberos ticket with authentication indicator 'password' in it. We will add passwordless authentications later, mimicking FreeIPA deployments.

Use of OTP preauthentication mechanism requires certain preconditions to be true for both Kerberos client and Kerberos KDC. We fulfill them by providing a Kerberos PKINIT configuration with a self-signed local CA, maintained by the certmonger. When localkdc-setup tool is executed, it requests the certificates and configures Kerberos system to use this self-signed CA for automatically providing Anonymous PKINIT feature with auto_fast_armor = true.

The combination of on-demand activating local KDC and on-demand authenticating PAM helper makes local KDC introduction transparent for migration of the existing deployments. Local KDC will not need creating additional Kerberos principals for existing users. Instead, it will fall back to ask their existing system passwords as Kerberos principal credentials.

Use of Kerberos tickets

Kerberos tickets obtained from the local KDC can be used for any of the local services that support GSSAPI. localkdc-setup already configures Kerberos services for common use cases:

host/... as the main service for this host. It is used by SSSD, by OpenSSH server and by pam_sss_gss PAM module
cifs/... as the Samba service
HTTP/... as the main HTTP service, which can be used by the Cockpit setup for local access from the browser running on the same system.

See man pam_sss_gss for more details on how PAM authentication with GSSAPI is configured and performed. With the default configuration sudo will be able to accept these tickets for the users allowed to use sudo or sudo -i services. Please note that due to how sudo is implemented, you will be prompted to enter a password by sudo. Just hit enter, then pam_sss_gss will be able to recognize the existing Kerberos ticket and authenticate the account.

Protocol transition and local KDC

OpenSSH server in Fedora supports protocol transition feature on systems where Kerberos is configured. It also works with local KDC for S4U2Self operation. The following SSH server configuration fragment allows to issue a Kerberos ticket for the user authenticated with any OpenSSH authentication method that doesn't result itself in Kerberos ticket:

Match user <username>
    GSSAPIAllowS4U2Self yes

The Kerberos ticket obtained through protocol transition can then be used for the operations which require a service ticket to host/... service:

authenticate with ssh client towards the same host as this user. You may use public SSH keys here, e.g.

  $ ssh -i ~/.ssh/my-key -l username localkdc.system
  $ klist
  $ ssh `hostname`
  [now logged into localkdc.system in a new session]

authenticate to sudo or any other PAM service with pam_sss_gss

Authentication towards other Kerberos services will require to perform S4U2Proxy operation which is currently not supported in local KDC.

I have built a test version of Local KDC in COPR `abbra/krb5-test`. ## Quick setup To test you need Fedora Rawhide (there is a build for Fedora 44 as well): ``` # dnf copr enable abbra/krb5-test # dnf install localkdc{,-kdb,-pam-auth,-selinux} ``` Optionally install Samba: ``` # dnf install samba samba-client ``` In order to setup local KDC, run `localkdc-setup` command: ``` # localkdc-setup ``` You'll get a deployment where local KDC is activated on demand whenever a Kerberos client such as `kinit` connects to the UNIX domain socket `/run/localkdc/kdc.sock`. All configuration is predefined, including Kerberos services for this host. The configuration is a bit opinionated: it sets up use of SSSD with `localkdc` domain that uses `proxy` ID provider pointing to `/etc/passwd + /etc/group` and authentication provider using Kerberos (`krb5`). It also configures PAM stack to allow `pam_sss_gss` module and permits use of Kerberos tickets for `sudo` and `sudo -i` authentication. ## User authentication None of the Kerberos principals for user accounts are there. This is intentional. If you create user accounts with `useradd <username> && passwd <username>` then the local KDC will be able to see the accounts through systemd's userdb interface and will be able to authenticate them using their passwords via PAM service `system-auth`. This flow is organized through the use of Kerberos OTP pre-authentication mechanism. As a result, you will see an OTP prompt when performing `kinit <username>`. A special `localkdc-pam-auth` helper will be triggered by the local KDC and will perform this authentication. After successful PAM authentication, local KDC will issue a Kerberos ticket with authentication indicator 'password' in it. We will add passwordless authentications later, mimicking FreeIPA deployments. Use of OTP preauthentication mechanism requires certain preconditions to be true for both Kerberos client and Kerberos KDC. We fulfill them by providing a Kerberos PKINIT configuration with a self-signed local CA, maintained by the `certmonger`. When `localkdc-setup` tool is executed, it requests the certificates and configures Kerberos system to use this self-signed CA for automatically providing Anonymous PKINIT feature with `auto_fast_armor = true`. The combination of on-demand activating local KDC and on-demand authenticating PAM helper makes local KDC introduction transparent for migration of the existing deployments. Local KDC will not need creating additional Kerberos principals for existing users. Instead, it will fall back to ask their *existing* system passwords as Kerberos principal credentials. ## Use of Kerberos tickets Kerberos tickets obtained from the local KDC can be used for any of the local services that support GSSAPI. `localkdc-setup` already configures Kerberos services for common use cases: - `host/...` as the main service for this host. It is used by SSSD, by OpenSSH server and by `pam_sss_gss` PAM module - `cifs/...` as the Samba service - `HTTP/...` as the main HTTP service, which can be used by the Cockpit setup for local access from the browser running on the same system. See man `pam_sss_gss` for more details on how PAM authentication with GSSAPI is configured and performed. With the default configuration `sudo` will be able to accept these tickets for the users allowed to use `sudo` or `sudo -i` services. Please note that due to how `sudo` is implemented, you will be prompted to enter a password by `sudo`. Just hit enter, then `pam_sss_gss` will be able to recognize the existing Kerberos ticket and authenticate the account. ## Protocol transition and local KDC OpenSSH server in Fedora supports protocol transition feature on systems where Kerberos is configured. It also works with local KDC for S4U2Self operation. The following SSH server configuration fragment allows to issue a Kerberos ticket for the user authenticated with any OpenSSH authentication method that doesn't result itself in Kerberos ticket: ``` Match user <username> GSSAPIAllowS4U2Self yes ``` The Kerberos ticket obtained through protocol transition can then be used for the operations which require a service ticket to `host/...` service: - authenticate with `ssh` client towards the same host as this user. You may use public SSH keys here, e.g. ``` $ ssh -i ~/.ssh/my-key -l username localkdc.system $ klist $ ssh `hostname` [now logged into localkdc.system in a new session] ``` - authenticate to `sudo` or any other PAM service with `pam_sss_gss` Authentication towards other Kerberos services will require to perform S4U2Proxy operation which is currently not supported in local KDC.

pboy removed the

meeting

label

2026-04-01 10:48:55 +00:00

Rows
Columns

Access networking home directory securely and SSH protocol transition feature #189

Quick setup

User authentication

Use of Kerberos tickets

Protocol transition and local KDC