Using openssh-server in container torizon/debian:3-bookworm

Technical Support
, ,
1

I’ve been successfully using an ssh server for development and debugging inside a container based on the image torizon/debian:2-bullseye. I can install the package and start it like this:

apt-get update
apt-get upgrade
apt-get install openssh-server
service ssh start

I figured that I really should use the newer version of the container torizon/debian:3-bullseye but the commands listed above no longer work in that version.

In bookworm apt-get update fails with messages about missing signatures:

Get:4 https://feeds.toradex.com/debian/snapshots/20240116T145428Z testing InRelease [15.1 kB]
Err:1 http://deb.debian.org/debian bookworm InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131 NO_PUBKEY F8D2585B8783D481

If I try apt-get install openssh-server with bookworm then I get this message:

Package openssh-server is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'openssh-server' has no installation candidate

Has the package openssh-server been deprecated in bookworm?

2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Greetings,

The issue you’re encountering with apt-get update failing due to missing signatures and the inability to install openssh-server in the torizon/debian:3-bookworm container is not due to the deprecation of the openssh-server package. Instead, it seems related to the Debian repository’s GPG keys not being recognized or missing in the container image, which prevents the package manager from securely fetching and installing packages.

To resolve the issue with missing GPG keys, you can manually add the missing keys by using the apt-key command with the key IDs mentioned in the error messages. However, it’s important to note that manually adding keys should be done with caution and understanding of the security implications. Here’s how you can add the keys:

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0E98404D386FA1D9 6ED0E7B82643E131 F8D2585B8783D481

After adding the missing keys, try running apt-get update again. This should resolve the issue with the missing signatures and allow you to update the package lists from the repositories securely.

Regarding the openssh-server package not being available, this could be a temporary issue with the Debian Bookworm repositories or a misconfiguration in your container’s sources list. Ensure that your /etc/apt/sources.list and any files in /etc/apt/sources.list.d/ are correctly configured to point to the Bookworm repositories. You might also want to ensure that your container has internet access and can reach the Debian repositories.

If the issue persists, consider checking the Debian package database to confirm that openssh-server is available for Bookworm and hasn’t been replaced or renamed. It’s unlikely that such a fundamental package would be deprecated without a clear alternative or migration path.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

High performance, low power Embedded Computing Systems | Toradex Developer Center.

3

Greetings @MikeS,

I was unable to reproduce this on my device. Using the torizon/debian:3-bookworm container image I can run apt-get update just fine and install openssh-server.

Looking at the error with apt-get update it seems like perhaps it was a server/network issue when trying to connect with the debian package servers. Is this issue reproducible for you?

Also the reason apt-get install failed is because apt-get update failed. Any apt-get install will likely fail until you succesfully run apt-get update beforehand.

Best Regards,
Jeremias

4

Thanks for testing that for me @jeremias.tx

I tried it again this morning just in case it was a temporary network issue but I see the same thing. I the block of text below I ran a bullseye container where apt-get worked, and then immediately tried a bookworm container on the same system where apt-get failed.

Is it possible that my problem comes from running a new container image on an older version of TorizonCore? (My version is shown in the block below). I’m using an older version of TorizonCore due to problems I encountered with creating device tree overlays with torizoncore-builder in the newer version of TorizonCore. Maybe I should try the new version again?

torizon@colibri-imx6-10634753:~$ uname -a
Linux colibri-imx6-10634753 5.4.193-5.7.2+git.f5d73fd6e9f8 #1-TorizonCore SMP Fri Jun 24 10:15:32 UTC 2022 armv7l armv7l armv7l GNU/Linux
torizon@colibri-imx6-10634753:~$ docker run --rm -it torizon/debian:2-bullseye
root@d8891fa5dab5:/# apt-get update
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:4 https://feeds.toradex.com/debian/snapshots/20220512T021145Z testing InRelease [13.0 kB]
Get:5 http://deb.debian.org/debian bullseye/main armhf Packages [7840 kB]
Get:6 http://deb.debian.org/debian-security bullseye-security/main armhf Packages [277 kB]
Get:7 http://deb.debian.org/debian bullseye-updates/main armhf Packages [16.3 kB]
Get:8 https://feeds.toradex.com/debian/snapshots/20220512T021145Z testing/main armhf Packages [24.4 kB]
Fetched 8379 kB in 11s (761 kB/s)
Reading package lists... Done
root@d8891fa5dab5:/# exit
exit
torizon@colibri-imx6-10634753:~$ docker run --rm -it torizon/debian:3-bookworm
root@d6f3cece097f:/# apt-get update
Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
Get:2 http://deb.debian.org/debian bookworm-updates InRelease [55.4 kB]
Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0 kB]
Get:4 https://feeds.toradex.com/debian/snapshots/20240116T145428Z testing InRelease [15.1 kB]
Err:1 http://deb.debian.org/debian bookworm InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131 NO_PUBKEY F8D2585B8783D481
5

@MikeS can you run the container with --security-opt seccomp=unconfined? I’m pretty sure this is a syscall blocking thing that changed from bullseye to bookworm together with a weird interaction from libseccomp and Docker that was solved in the newer releases.

We never experienced this because we officially only support the bookworm containers on Torizon OS 6 onwards.

6

As Leon has said, our bullseye containers are designed to work with our 5.X version Torizon OS, while our bookworm containers are designed for 6.X.

If you want to be using the newer bookworm containers I would strongly suggest migrating to 6.X. Otherwise you may run into other strange issues like this. Otherwise if you want to stay on that version of the OS then probably stay with the bullseye containers for stability.

Best Regards,
Jeremias

7

Yes, you’re right. When using TorizonCore 6.7 this works just fine with both the torizon/debian:2-bullseye and torizon/debian:3-bookworm images. When using TorizonCore 5.7 only torizon/debian:2-bullseye works. This makes sense to me now.

I’ll move ahead with TorizonCore 6.7 now and try to get the device tree overlays to work, that’s where I got stuck before with 6.x and reverted to 5.7/

8

Glad we were able to help clarify things for you.