No systemd service for sshd, even with openssh-server

[Sadoon-AlBader]

First of all, thanks for this awesome project! I'm very tempted to replace my current setup with this.

It seems that even after installing openssh-server

rpm-ostree install openssh-server

systemd cannot find the .service file, I can't find it either in /etc/systemd/system/multi-user.target.wants or in /usr/lib/systemd/system

I'm trying to ssh into my VM to setup some things and copy over files.

[RoyalOughtness]

First of all, thanks for this awesome project! I'm very tempted to replace my current setup with this.

It seems that even after installing openssh-server

rpm-ostree install openssh-server

systemd cannot find the .service file, I can't find it either in /etc/systemd/system/multi-user.target.wants or in /usr/lib/systemd/system

I'm trying to ssh into my VM to setup some things and copy over files.

Is your target case here a server? We deliberately remove openssh-server from images even though it's available in upstream images to reduce attack surface. We will be reintroducing it for server variations, with configuration hardening.

This issue tracks that: #58

If your use case is a desktop use case, I'm curious to know why ssh-server would be needed at all.

[Sadoon-AlBader]

If your use case is a desktop use case, I'm curious to know why ssh-server would be needed at all.

Actually I'm ssh'ing into the VM where I installed Kinoite because it's faster than using the VM's display, I don't see myself using ssh after I'm done configuring though.
Would be nice to be able to at least choose to enable it.

[RoyalOughtness]

If your use case is a desktop use case, I'm curious to know why ssh-server would be needed at all.

Actually I'm ssh'ing into the VM where I installed Kinoite because it's faster than using the VM's display, I don't see myself using ssh after I'm done configuring though. Would be nice to be able to at least choose to enable it.

if you are successfully layering openssh-server and the service file isn't present, that's an upstream issue one way or the other, either with rpm-ostree or that package. In the meantime, you can try to work around it by copying over your files while on a vanilla silverblue/kinoite image, then rebasing to secureblue

[Sadoon-AlBader]

if you are successfully layering openssh-server and the service file isn't present, that's an upstream issue one way or the other, either with rpm-ostree or that package. In the meantime, you can try to work around it by copying over your files while on a vanilla silverblue/kinoite image, then rebasing to secureblue

Yeah I expected this to be upstream, though rpm -ql openssh-server does list the systemd unit files on vanilla, very weird.
Thanks again!

[RoyalOughtness]

if you are successfully layering openssh-server and the service file isn't present, that's an upstream issue one way or the other, either with rpm-ostree or that package. In the meantime, you can try to work around it by copying over your files while on a vanilla silverblue/kinoite image, then rebasing to secureblue

Yeah I expected this to be upstream, though rpm -ql openssh-server does list the systemd unit files on vanilla, very weird. Thanks again!

I suspect that since we're removing it with a layer, and then you're adding it back with a layer, rpm-ostree is getting confused 😄

If you can repro this with an rpm-ostree remove and subsequent rpm-ostree install, and then the service files are missing, it would be good to get that reported to rpm-ostree as a bug on their end.

[Sadoon-AlBader]

If you can repro this with an rpm-ostree remove and subsequent rpm-ostree install, and then the service files are missing, it would be good to get that reported to rpm-ostree as a bug on their end.

rpm-ostree install --apply-live openssh-server

Inactive requests:
  openssh-server (already provided by openssh-server-9.3p1-9.fc39.x86_64)

That's the issue it seems yeah. rpm -qa afterwards show it's not installed.

[RoyalOughtness]

If you can repro this with an rpm-ostree remove and subsequent rpm-ostree install, and then the service files are missing, it would be good to get that reported to rpm-ostree as a bug on their end.

rpm-ostree install --apply-live openssh-server

Inactive requests:
  openssh-server (already provided by openssh-server-9.3p1-9.fc39.x86_64)

That's the issue it seems yeah. rpm -qa afterwards show it's not installed.

Please report this bug upstream, that seems like incorrect behavior.

[Sadoon-AlBader]

If you can repro this with an rpm-ostree remove and subsequent rpm-ostree install, and then the service files are missing, it would be good to get that reported to rpm-ostree as a bug on their end.

rpm-ostree install --apply-live openssh-server

Inactive requests:
  openssh-server (already provided by openssh-server-9.3p1-9.fc39.x86_64)

That's the issue it seems yeah. rpm -qa afterwards show it's not installed.

Please report this bug upstream, that seems like incorrect behavior.

To expand on this, it affects other removed packages like toolbox and podman. Before submitting a bugreport, I'd like to explore my options, in this case rpm-ostree options, perhaps we can force it to install some package it thinks is already there, in which case the bugreport could include that as a workaround.
I know it sounds counter-intuitive, but I'm eager to run Kinoite on my ppc64le box, which doesn't have great flatpak support and chromium is only available on Debian there.
So toolbox > deb environment > bwrap chromium > profit!
(and yes I do mean to rebuild secureblue for ppc64le later, seems easy enough all things considered)

EDIT: looks like someone has already submitted a similar issue:
coreos/rpm-ostree#4554

[Sadoon-AlBader]

Ok finally found the solution after RTFMing:

https://coreos.github.io/rpm-ostree/ex-replace/

In this case the command would be:

rpm-ostree override replace --experimental --from repo=fedora openssh-server

[RoyalOughtness]

To expand on this, it affects other removed packages like toolbox and podman.

There is no point trying to add these back. They're removed from secureblue because they don't work without unprivileged usernamespaces.

I know it sounds counter-intuitive, but I'm eager to run Kinoite on my ppc64le box

Kinoite or ublue-kinoite or secureblue kinoite?

yes I do mean to rebuild secureblue for ppc64le later, seems easy enough all things considered)

It won't be possible let alone easy. Upstream uBlue doesn't support ppc yet: ublue-os/boxkit#65 (comment)

[Sadoon-AlBader]

There is no point trying to add these back. They're removed from secureblue because they don't work without unprivileged usernamespaces.

Easy sysctl change, but I understand why it was disabled by default. It's also useful to actually be able to build secureblue itself since that requires podman.

It won't be possible let alone easy. Upstream uBlue doesn't support ppc yet: ublue-os/boxkit#65 (comment)

Shame, upstream Fedora ostree does support ppc64le. Second best thing is to apply some of the security features at least, or try to work on ublue supporting ppc64le.

[RoyalOughtness]

Easy sysctl change, but I understand why it was disabled by default. It's also useful to actually be able to build secureblue itself since that requires podman.

do NOT do this. This opens up a massive security hole.
GHSA-j2qp-rvxj-43vj
#87 (comment)

If you want to use podman, use ublue kinoite or stock kinoite.