#3413 Issue closed: sshd in the rescue image lacks an ed25519 host key, and after upgrade from EL 8 to EL 9 it will not start anymore

Labels: bug, fixed / solved / done

gdha opened issue at 2025-02-28 11:17:

ReaR version

v2.6 (and higher)

Describe the ReaR bug in detail

The recovery image on RHEL 9 fails to start-up the sshd daemon for 2 reasons;

  • /usr/share/empty.sshd is missing
  • the /etc/ssh/ssh_host_ed25519_key is missing

We must enhance script /etc/scripts/run-sshd

Platform

Linux x64

OS version

RHEL 9.5

Backup

NETFS

Storage layout

n/a

What steps will reproduce the bug?

No response

Workaround, if any

No response

Additional information

No response

gdha commented at 2025-03-03 13:01:

Reported at RedHat: https://access.redhat.com/support/cases/#/case/04075281

gdha commented at 2025-03-06 09:10:

Image

It worked as expected. We could login via a Putty session over the network on an EL9 system now.

gdha commented at 2025-03-14 12:41:

With PR #3415 merged we can close this issue.

pcahyna commented at 2025-03-21 18:43:

There were two issues, none of them is as general as "On EL9 sshd will not start anymore". The first one is that the rescue image lacks an ed25519 host key for ssh if one does not want ssh keys embedded in the image. This leads to ssh connections failing in an environment when the use of other keys has been disabled (which is not typical).
The second and more serious issue is that after an upgrade to EL 9 (or an upgrade of Fedora), the sshd user has the old $HOME left (the upgrade does not update the value), but the empty directory used for sshd privilege separation is different (and hardcoded in the sshd binary). Since the only source of information about the directory is the sshd user account and ReaR uses that to embed the directory in the image, the directory will be missing and sshd won't start. This does not happen in a fresh install. This was introduced by this Fedora change: https://src.fedoraproject.org/rpms/openssh/pull-request/14.
I adjusted the bug title accordingly.
By the way, I suspect that Debian has the same problem. I don't see anything in the scripts of the .deb openssh package to adjust the sshd user on upgrade: https://salsa.debian.org/ssh-team/openssh/-/commit/deabedcd80fd145a2eb350ad5a6a34670750a755

[Export of Github issue for rear/rear.]