#1148080 openssh: Purging openssh-server after installing openssh-server-gssapi deletes data and renders SSH unusable

#1148080#5
Date:
2026-09-16 19:21:38 UTC
From:
To:
Hi,

If openssh-server is purged after openssh-server-gssapi is installed,
the postrm script unconditionally removes configuration which it thinks
still belongs to openssh-server, while in fact, openssh-server-gssapi
has become the owner of that configuration. The deleted files involve
the host keys, sshd_config, and systemd unit activation, rendering the SSH
service unusable. openssh-client/openssh-client-gssapi has a similar problem,
although it is less severe.

Initial state:

root@host:/etc# dpkg -l | grep openssh
rc  openssh-client                                1:10.4p1-4                               amd64        secure shell (SSH) client, for secure access to remote machines
ii  openssh-client-gssapi                         1:10.5p1-1                               amd64        secure shell (SSH) client, with GSS-API support
ii  openssh-common                                1:10.5p1-1                               amd64        common files for OpenSSH
rc  openssh-server                                1:10.4p1-4                               amd64        secure shell (SSH) server, for secure access from remote machines
ii  openssh-server-gssapi                         1:10.5p1-1                               amd64        secure shell (SSH) server, with GSS-API key exchange
ii  openssh-sftp-server                           1:10.5p1-1                               amd64        secure shell (SSH) sftp server module, for SFTP access from remote machines
root@host:/etc# dpkg -L openssh-client
/etc
/etc/ssh
root@host:/etc# dpkg -L openssh-server
/etc
/etc/default
/etc/init.d
/etc/pam.d
/etc/ssh
/etc/ssh/sshd_config.d
/etc/sv
/etc/sv/ssh
/etc/sv/ssh/.meta
/etc/sv/ssh/log
/etc/ufw
/etc/ufw/applications.d


Configuration lost after purging openssh-client:

root@host:/etc# dpkg --purge openssh-client
(Reading database… 233916 files and directories currently installed.)
Purging configuration files for openssh-client (1:10.4p1-4)…
root@host:/etc# git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	deleted:    ssh/moduli
	deleted:    systemd/user/sockets.target.wants/ssh-agent.socket

no changes added to commit (use "git add" and/or "git commit -a")


Configuration lost after purging openssh-server:

root@host:/etc# git restore ssh/moduli systemd/user/sockets.target.wants/ssh-agent.socket
root@host:/etc# dpkg --purge openssh-server
(Reading database… 233916 files and directories currently installed.)
Purging configuration files for openssh-server (1:10.4p1-4)…
root@host:/etc# git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	deleted:    rc2.d/S03ssh
	deleted:    rc3.d/S03ssh
	deleted:    rc4.d/S03ssh
	deleted:    rc5.d/S03ssh
	deleted:    runit/runsvdir/default/ssh
	deleted:    ssh/ssh_host_ed25519_key
	deleted:    ssh/ssh_host_ed25519_key.pub
	deleted:    ssh/ssh_host_rsa_key
	deleted:    ssh/ssh_host_rsa_key.pub
	deleted:    ssh/sshd_config
	deleted:    systemd/system/multi-user.target.wants/ssh.service
	deleted:    systemd/system/ssh.service.wants/sshd-keygen.service
	deleted:    systemd/system/ssh.socket.wants/sshd-keygen.service
	deleted:    systemd/system/sshd.service
	deleted:    systemd/system/sshd.service.wants/sshd-keygen.service
	deleted:    systemd/system/sshd@.service.wants/sshd-keygen.service

no changes added to commit (use "git add" and/or "git commit -a")

IMHO the best way to solve this issue would be introducing
openssh-client-common and openssh-server-common packages, and moving all
the common configurationt to those packages.

Regards,
Gabor

#1148080#10
Date:
2026-09-18 12:10:47 UTC
From:
To:
Tricky.  I'm quite busy right now but will look as soon as I can.

This won't be enough, because at least the default sshd_config is
slightly different between the two flavours.  So we'll have to have some
other strategy anyway, at which point it may not be worth introducing
even more packages ...