Ubuntu 26.10 OpenSSH Bug: How Package Cleanup Can Break SSH Access

A routine cleanup can be more dangerous than the upgrade that preceded it. Ubuntu 26.10 has a documented OpenSSH packaging regression: after changing between the regular and GSSAPI variants, purging the removed package can delete configuration that the installed replacement still needs. On a server, that can cost you remote access.

What changed in Ubuntu 26.10?

Canonical released Ubuntu 26.10 “Stonking Stingray” on 15 October 2026. This is an interim release with nine months of support, ending in July 2027. Its release announcement places it in Ubuntu’s continuing security and platform work. The migration to Rust-based uutils coreutils is now complete, including cp, mv and rm.

Those changes deserve compatibility testing in their own right. They do not explain this SSH failure: the documented trigger is package cleanup. For administrators, the useful connection is operational. An interim release brings a shorter upgrade horizon and several moving parts; rehearse changes and recovery before applying them to a machine whose only entrance is SSH.

Two OpenSSH variants, two different requirements

The release notes describe separate source packages, openssh and openssh-gssapi, based on OpenSSH 10.5. Their relevant binary packages are:

GSSAPI connects applications to authentication mechanisms such as Kerberos, useful for ticket-based enterprise sign-on. Many key-based SSH installations do not need it. Canonical’s stated rationale is to reduce the exposed code and dependencies for those users while retaining the functionality for deployments that rely on it. The release notes also identify a substantial downstream Kerberos patch that upstream OpenSSH has not incorporated.

That is a legitimate security objective. The regression concerns the handover between packages. Each corresponding pair conflicts: installing one removes the other. The release upgrader looks for evidence of GSSAPI use when choosing a variant; fresh installations default to the regular variant. Check your actual packages rather than infer the result from your preferred authentication method.

Why an rc package is not an untidy installation

dpkg distinguishes removal from purging. Removal takes away a package’s installed program files while retaining configuration and removal bookkeeping. Purging also clears remaining configuration and invokes the package’s cleanup logic. Keeping configuration is intentional: uninstalling software should not necessarily destroy an administrator’s work.

In the dpkg-query status notation, the first character describes the requested action and the second the current state. ii means requested installation, currently installed. rc means requested removal, with configuration remaining. A third, normally blank column records errors. An rc entry does not mean that a second SSH daemon is running.

A regular-to-GSSAPI switch can therefore leave openssh-server at rc and openssh-server-gssapi at ii. That is the expected transition, not a repair request. apt remove and apt purge are different operations; autoremove must also be considered together with its options and local APT configuration.

Where the dangerous cleanup begins

Launchpad bug 2169738, filed on 6 October, identifies the failure in the removed package’s postrm maintainer script. Without the correction, cleanup can delete host keys and sshd_config and interfere with systemd activation, even though the counterpart now uses that configuration. The client has a related problem involving shared SSH configuration and system-wide known hosts.

The relevant chain is specific: a variant has been replaced, the old package retains cleanup state, and someone subsequently purges it while the counterpart is installed. A blanket script that purges every rc package can supply that final step. So can an explicit purge command or a cleanup tool configured to remove residual configuration.

An untouched installation of one variant does not meet that sequence. Neither does merely seeing an rc entry. A release upgrade or ordinary SSH login does not by itself demonstrate the purge bug. A surviving established connection also does not prove that new connections will work after configuration or service state has been damaged.

Fix status: published is not the same as proposed

No released regular-package SRU was visible in those records at this check. The correction being present in stonking-proposed is not evidence that a normal production machine has received it. Do not enable Proposed just to make a cleanup task possible. The bug records an i386 regression-test complication because the GSSAPI counterpart is not built for that architecture; that is a test/migration detail, not proof that every architecture loses SSH.

Direction matters. Purging the old regular package runs its script, even if the installed GSSAPI package is fixed. Updating the installed counterpart does not establish that the retained script of an rc package is safe. Older GSSAPI package revisions also predate the guard. Treat the table as a dated archive snapshot, not permission to purge every package with a familiar version number.

Start with read-only checks

cat /etc/os-release

Confirm Ubuntu and VERSION_ID="26.10". Other releases need their own assessment. Then inspect the package database:

dpkg -l 'openssh-*'

Look for a corresponding rc/ii pair, separately for client and server. The quotation marks prevent your shell from expanding the wildcard. A message that no matching package exists is not evidence of a damaged SSH installation.

apt-cache policy openssh-server openssh-server-gssapi openssh-client openssh-client-gssapi

This shows installed and candidate versions and the repositories known to the local APT cache; it does not refresh that cache. Candidates can differ with mirrors, pinning and enabled pockets. For the regular-server example, you can also read the retained cleanup script:

dpkg-query --control-show openssh-server postrm

This prints text; it does not execute the script. Substitute only the actual residual package you are investigating. If no script is available, investigate rather than improvise. Do not edit dpkg’s internal files to bypass cleanup.

A verified preventive workaround

Canonical’s documented precaution is to defer purging affected residual OpenSSH packages until the update. Exclude them from cleanup automation and review scripts that combine a package-state listing with purge, --purge or autopurge. An APT simulation helps review package selections, but does not run maintainer scripts and cannot prove that their filesystem effects are safe.

Verification boundary: this article is checked against documentation, archive records, packaging source and Canonical’s published test results. I did not reproduce it on a real Ubuntu 26.10 machine. The regression test switches variants, purges the old packages and checks that configuration and a host key survive. Its 11 October amd64 run passed. That validates the proposed correction in that test environment; it is not a local recovery test.

Recover through a console, not a hopeful restart

Save the surviving /etc/ssh tree, relevant service overrides and logs to a protected backup before changing files. Include host private keys, configuration snippets and authentication policy. If damage already occurred, preserve that state separately and retrieve a known-good earlier backup. My Linux configuration backup guide explains the wider backup distinction.

At the console, confirm which variant belongs on this host. A Kerberos deployment needs its GSSAPI support; installing the regular package as a shortcut may exchange a packaging problem for an authentication problem. Restore the correct configuration, snippets, ownership, permissions and original host keys from trusted backup. Do not replace a hardened configuration with a generic internet example.

If package-managed files need repair, first review a simulation for the chosen variant. This example applies only when the GSSAPI server is the intended installed package:

apt-get -s --reinstall install openssh-server-gssapi

The simulation makes no package changes. Read all proposed removals. An actual reinstall can run scripts and affect services; it is a console-assisted, host-specific decision. It is also not a complete configuration restore: dpkg can preserve a missing conffile as an intentional deletion, and generated or ucf-managed files have different handling. Avoid blanket force options. If original host keys are unrecoverable, replacement changes the server’s identity; distribute verified fingerprints through a trusted channel rather than tell users to ignore warnings.

After restoring files, validate without restarting:

sudo /usr/sbin/sshd -t

Success normally produces no output and a zero exit status. An error must be resolved first. A missing runtime directory in a stopped service can also need attention; do not assume every diagnostic is the purge bug.

systemctl status ssh.service ssh.socket --no-pager

sudo journalctl -u ssh.service -u ssh.socket -b -n 80 --no-pager

Check socket activation as well as the service: a listening socket with an inactive service can be normal before a connection. Status can return nonzero for inactive or failed units. Restore the intended activation arrangement before deliberately starting or reloading anything from the console. Only a fresh authenticated connection from another terminal confirms usable access. Check the expected account, privileges and authentication method before closing the recovery console.

USN-8928-1 is a separate security update

USN-8928-1, published on 14 October 2026, lists Ubuntu 26.04 LTS, 24.04 LTS and 22.04 LTS. It addresses nine CVEs involving SFTP paths, GSSAPI authentication state, compression, client usernames, certificate dates, decompression limits, tunnel restrictions and configuration handling. Those vulnerabilities have their own preconditions. The notice does not turn bug 2169738 into a remote exploit.

These are the notice’s LTS security-update versions, not the 26.10 purge-fix threshold. Apply your release’s supported security updates through the normal change process. Deferring unsafe cleanup is not a reason to freeze security maintenance.

What I would put in an administrator’s change plan

Inventory both SSH roles and both package states. Keep the precaution in cleanup automation until the relevant released fix and retained scripts have been assessed. Rehearse the variant transition and recovery in a disposable VM, preserve host identity, and test new connections after maintenance. For a production upgrade, make the July 2027 support deadline part of the plan.

The useful criticism here is precise: package replacement must preserve the configuration and identity inherited by its successor. Separating optional authentication support can reduce exposure; failing that handover creates an avoidable availability risk. The published correction and regression test address that boundary. Continue to check the tracker rather than treat this dated article as a live package feed.

Practical FAQ

Does every Ubuntu 26.10 server lose SSH?

No. This bug needs the affected variant-switch and purge sequence. Diagnose failed logins rather than assume this cause.

Should I purge an rc package to finish the upgrade?

No. The residual state is expected. For affected OpenSSH packages, leaving it alone is the documented precaution.

Does GSSAPI Fix Released mean both directions are safe?

No. The old package’s cleanup script matters. The regular-package fix was still in Proposed at this check.

Will reinstalling recover my custom policy and host identity?

Do not rely on it. Preserve and restore trusted backups, then validate configuration and a new login.

Official sources and further reading

• Ubuntu 26.10 release notes: lifecycle, coreutils, variants and purge precaution.
• Launchpad bug 2169738: impact, SRU plan and task-specific status; also available through the Launchpad API.
• Stonking openssh and openssh-gssapi publication histories: release versus proposed packages.
• Ubuntu openssh server cleanup source and packaging changelog: the guard added in revision 1:10.5p1-1ubuntu3.
• Canonical’s release announcement and USN-8928-1.
• dpkg, dpkg-query and apt-get manuals; Ubuntu’s OpenSSH administration guide.

Research checked on 19 October 2026. Archive versions were cross-checked through Launchpad’s source API and amd64 binary publications. Commands are documentation-reviewed examples, not results from a local Ubuntu 26.10 installation.