Awesome, thank you! This reproducer (after adapting for LXD) does catch
the bug (and verifies that it's gone on my fixed patch), so I'm now
getting the ball rolling on the Resolute SRU.


(For the SRU team: the verification script mentioned in the test plan is 
attached to this comment)

** Description changed:

+ [ Impact ]
+ 
+ * Name canonicalization with PAM is currently not working on Resolute, causing
+   problems with SSSD. ssh logins that should succeed are failing.
+ 
+ * The bug is gone in Stonking, fixed by the most recent merge (currently 
+   in proposed). To fix this on Resolute, we cherry-pick a patch
+   from upstream.
+ 
+ [ Test Plan ]
+ 
+ * The reproduction Docker image provided by Christoph in #5 has been adapted
+   into a one shot script for use in an LXD container, attached in #6. 
+   Running this script verifies the existence or nonexistence of the bug.
+ 
+ [ Where problems could occur ]
+ 
+ * This is a specifically cherry-picked set of commits from upstream for 
+   this specific usage path, there might later be some additional errant
+   behavior discovered which would necessitate another SRU.
+ 
+ * Different distributions settled on different patches for this problem.
+   This patch follows upstream, but it's possible that upstream may 
+   change its mind.
+ 
+ [ Original Bug ]
  Hi,
  
  We encountered a regression since trying Ubuntu 26.04 with our working
  config authenticating using short names against Active Directory joined
  hosts.
  
  I am letting you know I opened an issue upstream about this
  https://github.com/SSSD/sssd/issues/8682
  
  ### Findings
  
  Since OpenSSH 10.1p1, a strict username consistency check was introduced
  in PAM authentication:
  
  Initial PR : https://github.com/openssh/openssh-portable/pull/521
  Commit : 
https://github.com/openssh/openssh-portable/commit/140bae1df2b7246bb43439d039bf994159973585
  
  This change enforces that the username returned by PAM must exactly
  match the username provided to sshd.
  
  This breaks a common and documented SSSD configuration using Active
  Directory with short names :
  
  ```
  [sssd]
  ...
  domain_resolution_order = ad.example, domain2.example
  ...
  
  [domain/ad.example]
  use_fully_qualified_names = False
  ```
  
  In this setup:
  - Users authenticate using short names (e.g. `user1`)
  - SSSD internally canonicalizes identities to fully qualified names 
(`[email protected]`)
  - PAM returns the canonical name
  
  As a result, OpenSSH rejects authentication due to mismatch with the
  error `PAM user "user1" does not match expected "[email protected]"`
  
  ### Environment
  
  - OS: Ubuntu Server 26.04
  - OpenSSH: 10.2p1
  - SSSD: 2.12
  - realmd: 0.17.1
  - Directory: Active Directory
  
  Working comparison:
  - Ubuntu Server 24.04 (OpenSSH 9.6p1)
  
  ### SSSD configuration
  
  ```
  [sssd]
  domains = lab.internal
  domain_resolution_order = lab.internal
  
  [domain/lab.internal]
  id_provider = ad
  ad_domain = lab.internal
  krb5_realm = lab.internal
  use_fully_qualified_names = False
  fallback_homedir = /home/%u@%d
  default_shell = /bin/bash
  ldap_id_mapping = True
  cache_credentials = True
  ```
  
  ### Steps to reproduce
  1. Join AD domain via realmd with standard settings
  2. Configure sssd for short names with `domain_resolution_order = ad.example` 
and `use_fully_qualified_names = False`
  3. Restart sssd and sshd
  4. Attempt SSH login `ssh user1@server`
  
  ### Expected result
  
  Authentication succeeds using short username (`user1`), consistent with:
  - `su - user1`
  - `pamtester sshd user1 authenticate`
  - `getent passwd user1`
  
  ### Actual result
  
  Authentication fails with:
  
  ```
  sshd-session: pam_sss(sshd:auth): authentication success; logname= uid=0 
euid=0 tty=ssh ruser= rhost=192.168.0.1
  sshd-session: debug1: PAM user "user1" does not match expected 
"[email protected]"
  sshd-session: debug1: PAM: password authentication failed for user1: User not 
known to the underlying authentication module
  sshd-session: Failed password for user1 from 192.168.0.1 port 50308 ssh2
  ```
  
  However:
  - PAM authentication itself succeeds
  - Authenticating using FQDN `ssh [email protected]@server` succeeds
  
  ### Analysis
  
  - SSSD canonicalizes `user1` → `[email protected]`
  - PAM returns canonical username
  - OpenSSH ≥10.1p1 enforces strict equality between:
-   - requested username
-   - PAM-returned username
+   - requested username
+   - PAM-returned username
  
  This creates an incompatibility between:
  - SSSD name canonicalization
  - OpenSSH security hardening
  
  ### Impact
  
  - Breaks SSH login with short usernames
  - Affects all modern distributions shipping OpenSSH ≥10.1p1
  - Forces administrators to apply workarounds, losing functionality
  
  This reduces usability and breaks long-standing configurations.
  
  ### Workarounds
  
  - Set in sssd subdomain section `full_name_format = %1$s`
  - Or enforce FQDN logins
  
  Both are suboptimal in mixed environments.
  
  ### Proposed solution
  
  SSSD should adapt to OpenSSH’s stricter behavior.
  
  ### References
  
  - 
https://lists.mindrot.org/pipermail/openssh-unix-dev/2025-February/041798.html
  - Shortnames in trusted domains : https://sssd.io/design-pages/shortnames.html
  - https://github.com/SSSD/sssd/issues/4748 seems similar somehow
  
  _Disclaimer: This report was made with the help of AI with my
  troubleshooting_

** Merge proposal linked:
   
https://code.launchpad.net/~graysonwolf/ubuntu/+source/openssh/+git/openssh/+merge/507048

** Attachment added: "repro-lxd.sh"
   
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2151817/+attachment/5978455/+files/repro-lxd.sh

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2151817

Title:
  SSSD incompatible with OpenSSH ≥10.1p1 PAM username consistency check
  when using short names

To manage notifications about this bug go to:
https://bugs.launchpad.net/sssd/+bug/2151817/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to