** Description changed: [Summary] After upgrading openssh-server from 1:9.6p1-3ubuntu13.16 to 1:9.6p1-3ubuntu13.18 on Ubuntu 24.04 LTS, root public-key logins fail on hosts configured with "PermitRootLogin forced-commands-only". The client authenticates successfully and is then immediately disconnected. sshd's privilege-separation monitor terminates the connection with a fatal error. This breaks any unattended root-key SSH automation on such hosts (backups, replication, orchestration, monitoring). The failure is silent from the operator's point of view: the automation simply stops working. [Regression] Working: 1:9.6p1-3ubuntu13.16 Broken: 1:9.6p1-3ubuntu13.18 (uploaded 2026-07-09) No configuration was changed. The only change on the affected host was the unattended-upgrades run that installed .18. Automation was working 56 minutes before that upgrade and has failed on every attempt since. /var/log/dpkg.log: - 2026-05-06 06:15:41 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13.15 1:9.6p1-3ubuntu13.16 - 2026-08-14 06:56:31 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13.16 1:9.6p1-3ubuntu13.18 + 2026-05-06 06:15:41 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13.15 1:9.6p1-3ubuntu13.16 + 2026-08-14 06:56:31 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13.16 1:9.6p1-3ubuntu13.18 We have not tested .17. [Environment] Ubuntu 24.04.4 LTS (noble) openssh-server 1:9.6p1-3ubuntu13.18 kernel 6.8.0-79-generic Client and server both on the same version. [Relevant sshd_config on the server] - PermitRootLogin forced-commands-only - PubkeyAuthentication yes - PasswordAuthentication no - UsePAM yes - LogLevel VERBOSE - StrictModes yes + PermitRootLogin forced-commands-only + PubkeyAuthentication yes + PasswordAuthentication no + UsePAM yes + LogLevel VERBOSE + StrictModes yes [Relevant /root/.ssh/authorized_keys on the server] - no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh- + no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh- ed25519 AAAA... automation-key Note there is NO command="..." option on this key. The file has been unchanged since 2025-11-25 and worked throughout with .16 and earlier. - [Steps to reproduce] + [Test Plan] - 1. Ubuntu 24.04 server with the sshd_config above. - 2. Add an ed25519 key to /root/.ssh/authorized_keys with restriction options but - no command= option. - 3. From another host holding the matching private key: ssh root@server true + On a resolute system: + + 1. Generate key pair + $ ssh-keygen -t ed25519 -C "<your-mail>" + + 2. Add pub key to: ~/.ssh/authorized_keys + command="/bin/echo FORCED_COMMAND_SUCCESS" ssh-ed25519 ..... + + 3. Login with root + + $ ssh -i ~/.ssh/<private-key> root@localhost + + This should fail with the log: + + $ journalctl -u ssh + .. + ***: fatal: monitor_child_preauth: unexpected authentication from 102 + ... + + With the proposed fix, the command should succeed with output: + + FORCED_COMMAND_SUCCESS + Connection to localhost closed. [Expected result] Either the command runs, or sshd refuses the login cleanly with "ROOT LOGIN REFUSED" and the client reports "Permission denied (publickey)". [Actual result] Client side: - debug1: Server accepts key: /root/.ssh/id_ed25519 ED25519 SHA256:<redacted> - Authenticated to server ([192.0.2.10]:22) using "publickey". - debug1: channel 0: new session [client-session] (inactive timeout: 0) - debug2: channel 0: send open - debug1: Requesting [email protected] - debug1: Entering interactive session. - debug1: pledge: network - client_loop: send disconnect: Broken pipe + debug1: Server accepts key: /root/.ssh/id_ed25519 ED25519 SHA256:<redacted> + Authenticated to server ([192.0.2.10]:22) using "publickey". + debug1: channel 0: new session [client-session] (inactive timeout: 0) + debug2: channel 0: send open + debug1: Requesting [email protected] + debug1: Entering interactive session. + debug1: pledge: network + client_loop: send disconnect: Broken pipe Exit code 255. Server side (/var/log/auth.log, LogLevel VERBOSE): - sshd[1910601]: Root login accepted for forced command. [preauth] - sshd[1910601]: fatal: monitor_child_preauth: unexpected authentication from 102 + sshd[1910601]: Root login accepted for forced command. [preauth] + sshd[1910601]: fatal: monitor_child_preauth: unexpected authentication from 102 [Analysis] Two things look wrong. 1. sshd logs "Root login accepted for forced command" even though the key carries - NO command= option and no ForceCommand applies to this connection. Global - ForceCommand is unset; the only ForceCommand in the config is inside a - "Match Group ftp" block, and root is not a member of that group (verified with - `id root`). Under forced-commands-only with no forced command, - auth_root_allowed() should log "ROOT LOGIN REFUSED" and deny. It appears - auth_opts->force_command is being seen as non-NULL when it should not be. + NO command= option and no ForceCommand applies to this connection. Global + ForceCommand is unset; the only ForceCommand in the config is inside a + "Match Group ftp" block, and root is not a member of that group (verified with + `id root`). Under forced-commands-only with no forced command, + auth_root_allowed() should log "ROOT LOGIN REFUSED" and deny. It appears + auth_opts->force_command is being seen as non-NULL when it should not be. 2. The unprivileged child then sends monitor request type 102 - (MONITOR_REQ_PAM_ACCOUNT) to the monitor, which does not permit that request - in its current state and calls fatal(), tearing down the connection. + (MONITOR_REQ_PAM_ACCOUNT) to the monitor, which does not permit that request + in its current state and calls fatal(), tearing down the connection. The client sees USERAUTH_SUCCESS before the monitor kills the connection, which is why authentication appears to succeed and the session then dies immediately. We suspect a side effect of one of the authentication-path patches in .18 -- CVE-2026-60000 (MaxAuthTries mishandling, auth2-gss.c) and CVE-2026-60001 (minimum authentication delay in GSSAPI and keyboard-interactive) both touch auth dispatch -- but we have not bisected the patches. [Workaround] None confirmed at time of filing. Candidates under test: - - PermitRootLogin prohibit-password - - moving the automation off root to a delegated unprivileged user + - PermitRootLogin prohibit-password + - moving the automation off root to a delegated unprivileged user Note that downgrading is not generally available: on a standard noble mirror the only versions offered are 1:9.6p1-3ubuntu13.18 and the original unpatched 1:9.6p1-3ubuntu13. 1:9.6p1-3ubuntu13.16 is no longer in the archive, so affected sites cannot roll back without a locally cached .deb. [Additional notes] "PermitRootLogin forced-commands-only" with key-based root automation is a documented and widely used pattern -- sshd_config(5) describes it as "useful for taking remote backups even if root login is normally not allowed". Hosts using it lose all root-key automation on upgrade, with no error visible unless someone is watching the automation's own exit codes.
** Description changed: - [Summary] + [Impact] After upgrading openssh-server from 1:9.6p1-3ubuntu13.16 to 1:9.6p1-3ubuntu13.18 on Ubuntu 24.04 LTS, root public-key logins fail on hosts configured with "PermitRootLogin forced-commands-only". The client authenticates successfully and is then immediately disconnected. sshd's privilege-separation monitor terminates the connection with a fatal error. - This breaks any unattended root-key SSH automation on such hosts (backups, - replication, orchestration, monitoring). The failure is silent from the - operator's point of view: the automation simply stops working. - - [Regression] - - Working: 1:9.6p1-3ubuntu13.16 - Broken: 1:9.6p1-3ubuntu13.18 (uploaded 2026-07-09) - - No configuration was changed. The only change on the affected host was the - unattended-upgrades run that installed .18. Automation was working 56 minutes - before that upgrade and has failed on every attempt since. - - /var/log/dpkg.log: - 2026-05-06 06:15:41 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13.15 1:9.6p1-3ubuntu13.16 - 2026-08-14 06:56:31 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13.16 1:9.6p1-3ubuntu13.18 - - We have not tested .17. - - [Environment] - - Ubuntu 24.04.4 LTS (noble) - openssh-server 1:9.6p1-3ubuntu13.18 - kernel 6.8.0-79-generic - Client and server both on the same version. - - [Relevant sshd_config on the server] - - PermitRootLogin forced-commands-only - PubkeyAuthentication yes - PasswordAuthentication no - UsePAM yes - LogLevel VERBOSE - StrictModes yes - - [Relevant /root/.ssh/authorized_keys on the server] - - no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh- - ed25519 AAAA... automation-key - - Note there is NO command="..." option on this key. The file has been unchanged - since 2025-11-25 and worked throughout with .16 and earlier. - [Test Plan] On a resolute system: - 1. Generate key pair + 1. Generate key pair: $ ssh-keygen -t ed25519 -C "<your-mail>" 2. Add pub key to: ~/.ssh/authorized_keys + + $ cat ~/.ssh/authorized_keys command="/bin/echo FORCED_COMMAND_SUCCESS" ssh-ed25519 ..... 3. Login with root $ ssh -i ~/.ssh/<private-key> root@localhost This should fail with the log: $ journalctl -u ssh .. ***: fatal: monitor_child_preauth: unexpected authentication from 102 ... With the proposed fix, the command should succeed with output: FORCED_COMMAND_SUCCESS Connection to localhost closed. - [Expected result] + [ Where problems could occur ] - Either the command runs, or sshd refuses the login cleanly with - "ROOT LOGIN REFUSED" and the client reports "Permission denied (publickey)". + The fix only changes sshauthopt_serialise() so that "true"/"yes" are serialised + for force_command / cert_principals only when those fields are actually + non-NULL (matching the deserialisation side). It affects the + privilege-separation serialisation of authentication options exchanged between + the unprivileged child and the monitor. - [Actual result] + If the change were wrong, the possible impact would be limited to the + authentication path: + - forced-command keys could be misinterpreted (a forced command dropped, or + spuriously applied), or + - authorized_keys with restriction/certificate options could be evaluated + incorrectly. - Client side: + [ Other Info ] - debug1: Server accepts key: /root/.ssh/id_ed25519 ED25519 SHA256:<redacted> - Authenticated to server ([192.0.2.10]:22) using "publickey". - debug1: channel 0: new session [client-session] (inactive timeout: 0) - debug2: channel 0: send open - debug1: Requesting [email protected] - debug1: Entering interactive session. - debug1: pledge: network - client_loop: send disconnect: Broken pipe - Exit code 255. - - Server side (/var/log/auth.log, LogLevel VERBOSE): - - sshd[1910601]: Root login accepted for forced command. [preauth] - sshd[1910601]: fatal: monitor_child_preauth: unexpected authentication from 102 - - [Analysis] - - Two things look wrong. - - 1. sshd logs "Root login accepted for forced command" even though the key carries - NO command= option and no ForceCommand applies to this connection. Global - ForceCommand is unset; the only ForceCommand in the config is inside a - "Match Group ftp" block, and root is not a member of that group (verified with - `id root`). Under forced-commands-only with no forced command, - auth_root_allowed() should log "ROOT LOGIN REFUSED" and deny. It appears - auth_opts->force_command is being seen as non-NULL when it should not be. - - 2. The unprivileged child then sends monitor request type 102 - (MONITOR_REQ_PAM_ACCOUNT) to the monitor, which does not permit that request - in its current state and calls fatal(), tearing down the connection. - - The client sees USERAUTH_SUCCESS before the monitor kills the connection, which - is why authentication appears to succeed and the session then dies immediately. - - We suspect a side effect of one of the authentication-path patches in .18 -- - CVE-2026-60000 (MaxAuthTries mishandling, auth2-gss.c) and CVE-2026-60001 - (minimum authentication delay in GSSAPI and keyboard-interactive) both touch auth - dispatch -- but we have not bisected the patches. - - [Workaround] - - None confirmed at time of filing. Candidates under test: - - PermitRootLogin prohibit-password - - moving the automation off root to a delegated unprivileged user - - Note that downgrading is not generally available: on a standard noble mirror the - only versions offered are 1:9.6p1-3ubuntu13.18 and the original unpatched - 1:9.6p1-3ubuntu13. 1:9.6p1-3ubuntu13.16 is no longer in the archive, so affected - sites cannot roll back without a locally cached .deb. - - [Additional notes] - - "PermitRootLogin forced-commands-only" with key-based root automation is a - documented and widely used pattern -- sshd_config(5) describes it as "useful for - taking remote backups even if root login is normally not allowed". Hosts using it - lose all root-key automation on upgrade, with no error visible unless someone is - watching the automation's own exit codes. + - Upstream fix / PR: https://github.com/openssh/openssh-portable/pull/712 + - Verified by the reporter on NOBLE against a PPA build + (1:9.6p1-3ubuntu13.20~ppa...) on a clean Ubuntu 24.04 container: forced + commands run, unforced keys are cleanly refused, no fatal crash. + PPA: https://launchpad.net/~hectorcao/+archive/ubuntu/lp2166842 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166842 Title: sshd: fatal "monitor_child_preauth: unexpected authentication from 102" breaks root public-key login with PermitRootLogin=forced- commands-only + UsePAM=yes (regression in 1:9.6p1-3ubuntu13.18) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2166842/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
