# OpenSSH on a No-systemd Debian/antiX System

## The Problem

Installing an OpenSSH server on an older Debian/antiX system can fail when
package versions or build variants do not match.

A typical situation looks like this:

```text
openssh-client   7.9...nosystemd1
openssh-server   7.9...deb10u2
```

APT expects the dependencies of the installed packages to be satisfied by
compatible package versions. Mixing packages from different repositories or
build variants can therefore produce dependency errors.

A second common obstacle is `libsystemd0`.

Even on a system that does **not** use systemd as its init system, some
Debian-built packages may still depend on `libsystemd0` as a shared library.

This is an important distinction:

```text
systemd as init system
        
libsystemd0 as a shared library
```

Installing or replacing the init system is therefore not the correct way to
solve a library dependency.

---

# First Principle: Keep the Package Set Consistent

Before changing anything, inspect the installed SSH packages:

```bash
dpkg -l | grep -E "openssh|ssh"
```

Also inspect the available versions:

```bash
apt-cache policy openssh-client openssh-server libsystemd0
```

The goal is to avoid mixing:

* Debian packages with antiX-specific variants
* different repository generations
* `nosystemd` and regular packages where their dependencies are incompatible

---

# Option 1: Use a Consistent Debian Package Set

If the system is intended to use the regular Debian OpenSSH packages, first
remove a mismatched client package:

```bash
sudo apt remove --purge openssh-client
sudo apt autoremove --purge
```

Then install a client version compatible with the available server package.

For example:

```bash
sudo apt install openssh-client=1:7.9p1-10+deb10u2
```

The exact version must match what is actually available in the configured
repositories.

Do not copy an old version number blindly. Check it first with:

```bash
apt-cache policy openssh-client
```

---

# The `libsystemd0` Dependency

If the OpenSSH server requires `libsystemd0`, check whether a suitable
package is available:

```bash
apt-cache policy libsystemd0
```

For an older Debian 10-based system, a version such as:

```text
241-7~deb10u8
```

may be appropriate, depending on the repository snapshot being used.

If that exact version is available:

```bash
sudo apt install libsystemd0=241-7~deb10u8
```

If it is **not** available, do not force the package installation.

The repository may be incomplete, the package index may be stale, or the
system may be mixing repositories from different releases.

Check:

```bash
apt update
apt-cache policy libsystemd0
```

before proceeding further.

---

# Install the OpenSSH Server

Once the package set is consistent:

```bash
sudo apt install --no-install-recommends openssh-server
```

Using `--no-install-recommends` can be useful on a minimal antiX installation
where unnecessary desktop or systemd-related components are undesirable.

It does **not**, however, override mandatory package dependencies.

---

# What About `systemd-helper`?

A package such as `systemd-helper` may be useful on a no-systemd system when
Debian package maintainer scripts expect certain systemd-related commands to
exist.

Its role should not be confused with `libsystemd0`.

```text
systemd-helper
    
provides compatibility for certain service-management operations

libsystemd0
    
provides a shared library required by applications

systemd
    
the actual system and service manager
```

These are separate things.

Installing a compatibility helper does not replace a required shared library.

---

# Option 2: Use the antiX `nosystemd` Stack

If the machine is intentionally running antiX without systemd, another
approach is to keep the SSH packages within the same `nosystemd` ecosystem.

The important principle is consistency:

```text
openssh-client
openssh-server
sftp
    
compatible antiX / nosystemd packages
```

rather than:

```text
nosystemd client
        +
regular Debian server
        +
mixed dependencies
```

Check what the repositories actually provide:

```bash
apt-cache policy openssh-client openssh-server
```

If compatible antiX `nosystemd` packages are available, this can be the cleaner
solution for a minimal antiX installation.

---

# Choosing the Path

There are essentially two sane approaches.

### Regular Debian package set

Use the standard Debian OpenSSH packages and satisfy their dependencies,
including `libsystemd0` if required.

```text
Debian OpenSSH client
        +
Debian OpenSSH server
        +
required libraries
```

The system does **not** need to use systemd as its init system merely because
a package depends on `libsystemd0`.

### Consistent antiX `nosystemd` set

Use antiX-provided packages built for the no-systemd environment.

```text
antiX nosystemd client
        +
antiX nosystemd server
        +
matching dependencies
```

For a minimal antiX installation, this may be the cleaner approach.

---

# The Important Distinction

The problem is not necessarily:

> "OpenSSH needs systemd."

The actual problem may be:

> "This particular OpenSSH package was built with a dependency on
> `libsystemd0`."

Those are very different statements.

A no-systemd system can still contain libraries originating from the systemd
project. Installing a library does not mean replacing the system's init
system.

---

# Before Changing Anything

On an old system, inspect the package situation first:

```bash
apt-cache policy openssh-client openssh-server libsystemd0
```

and:

```bash
dpkg -l | grep -E "openssh|dropbear|systemd|libsystemd"
```

This usually tells you more than immediately trying to install another package.

**Do not force a package into the system simply because its name looks right.**

First determine:

1. Which release the package belongs to.
2. Which repository provides it.
3. Which variant is installed.
4. Which dependencies it requires.
5. Whether the repository contains compatible versions.

On older machines, keeping the package ecosystem internally consistent is
usually worth more than finding a clever one-command workaround.

---

## Summary

```text
Problem:
    Mixed OpenSSH package variants
            +
    missing or incompatible dependencies

Avoid:
    replacing the init system
    forcing unrelated package versions
    mixing repository generations

Prefer:
    consistent Debian packages
        OR
    consistent antiX nosystemd packages

Remember:
    systemd  libsystemd0
    systemd-helper  libsystemd0
```

The practical lesson is simple:

**Solve the package dependency problem, not the init-system problem.**