https://bugzilla.mindrot.org/show_bug.cgi?id=3978
Bug ID: 3978
Summary: `sshd_config`: GSSAPI directives renamed/broken in
10.4 (`GSSAPIAuthentication` → `GssAuthentication`
etc.), rejected with "Bad configuration option"
Product: Portable OpenSSH
Version: 10.4p1
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: sshd
Assignee: [email protected]
Reporter: [email protected]
Environment:
- OpenSSH 10.4p1 (portable), built from clean upstream source
(openssh-10.4p1.tar.gz)
- ./configure --with-kerberos5=/usr --with-pam ... (GSSAPI enabled,
confirmed via
"checking for gssapi support... yes")
- Ubuntu 22.04 build host, MIT Kerberos (libkrb5-dev)
- Working fine on 10.3p1 with identical build flags/environment —
regression appeared
exclusively after bumping to 10.4p1
Description:
After upgrading from 10.3p1 to 10.4p1 with no sshd_config changes, sshd
fails on every
connection (re-exec on accept) with:
```
sshd[PID]: error: /etc/ssh/sshd_config: line 25: Bad configuration
option: GSSAPIStrictAcceptorCheck
sshd[PID]: error: /etc/ssh/sshd_config: line 26: Bad configuration
option: GSSAPICleanupCredentials
sshd[PID]: error: /etc/ssh/sshd_config: line 53: Bad configuration
option: GSSAPIAuthentication
sshd[PID]: fatal: /etc/ssh/sshd_config line 53: Directive
'GSSAPIAuthentication' is not allowed within a Match block
```
Client side: "kex_exchange_identification: read: Connection reset by
peer" on every new
connection — the process aborts before sending the SSH banner. Existing
sessions are
unaffected until they disconnect and reconnect (config is re-parsed on
each re-exec).
The error is sBadOption ("Bad configuration option"), not sUnsupported
("Unsupported
option") — the parser doesn't recognize the token at all. This is not a
compiled-without-GSSAPI situation (that hits sUnsupported and only
warns) — it's a
genuine parse-table regression.
Root cause:
servconf.h's X-macro table for the GSSAPI group
(SSHD_CONFIG_ENTRIES_GSS) generates the
public config-token string from the macro's enum-name argument via
SSHCONF_KW(conf,flags) { #conf, s##conf, flags }. Every other directive
in the X-macro
schema passes the full config token as that argument (e.g.
PasswordAuthentication,
PubkeyAuthentication). The GSSAPI group instead passes the abbreviated
internal enum
name:
Directive Expected token Actual
generated token
GSSAPIAuthentication GSSAPIAuthentication
GssAuthentication
GSSAPICleanupCredentials GSSAPICleanupCredentials
GssCleanupCreds
GSSAPIDelegateCredentials GSSAPIDelegateCredentials
GssDelegateCreds
GSSAPIStrictAcceptorCheck GSSAPIStrictAcceptorCheck
GssStrictAcceptor
i.e. the internal/abbreviated identifier leaked into the public
sshd_config keyword
surface. Any existing sshd_config using the documented GSSAPI*
directive names breaks
outright on 10.4, with no deprecation warning or migration path — a
hard parse error
(fatal when the directive is inside a Match block, as GSSAPI directives
commonly are
for selective Kerberos auth).
Compared 10.3p1 vs 10.4p1 upstream source directly:
- servconf.c (10.3p1, static table): { "gssapiauthentication",
sGssAuthentication,
SSHCFG_ALL } — correct token.
- servconf.h (10.4p1, X-macro): SSHCONF_INTFLAG(gss_authentication,
GssAuthentication,
...) — token derives from GssAuthentication, not
GSSAPIAuthentication.
- configure.ac GSSAPI/Kerberos detection is otherwise unchanged between
the two tags —
this is a pure servconf table-generation regression, not a
build/detection issue.
How reproducible: Always
Steps to Reproduce:
1. Build OpenSSH 10.4p1 with --with-kerberos5=<path> (any
GSSAPI-enabling config).
2. Put in sshd_config:
GSSAPIAuthentication yes
(top-level, or inside a Match block as commonly used for selective
Kerberos auth)
3. Run: sshd -t -f sshd_config
Actual Results:
Bad configuration option: GSSAPIAuthentication
Expected Results:
Config accepted, GSSAPI authentication directive applied as in 10.3p1
and earlier.
Suggested fix:
Restore the original token strings for the GSSAPI group in servconf.h,
matching the
pattern every other X-macro entry already uses, e.g.:
SSHCONF_INTFLAG(gss_authentication, GSSAPIAuthentication, SSHCFG_ALL)
SSHCONF_INTFLAG(gss_cleanup_creds, GSSAPICleanupCredentials,
SSHCFG_ALL)
SSHCONF_INTFLAG(gss_deleg_creds, GSSAPIDelegateCredentials,
SSHCFG_ALL)
SSHCONF_INTFLAG(gss_strict_acceptor, GSSAPIStrictAcceptorCheck,
SSHCFG_ALL)
(exact macro name/arity may differ — matching whatever's used elsewhere
in the same
table.)
Related:
Same regression already reported downstream — Arch Linux packaging
issue #30
"GSSAPI stopped working when upgraded to 10.4p1-1":
https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/work_items/30
--
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
[email protected]
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
