4 ms·
> I can't fix Do not be afraid! (I've messed with quite a few very ancient and messy systems, like Gentoos of a legal drinking age. Dissected their guts, extra
by drdaeman 4y ago
> I can't fix
Do not be afraid! (I've messed with quite a few very ancient and messy systems, like Gentoos of a legal drinking age. Dissected their guts, extracted their hearts, made LD_PRELOAD crutches, containerized stuff to run on modern hardware - this kind of mix of software necromancery and archeology. It's not trivial, but quite doable.)
Fortunately, SSH daemons are quite isolated components, so they can almost always be updated without affecting the system.
It's possible to build a completely static OpenSSH daemon binary, and replace the ancient /usr/bin/sshd on the most ancient OS. And it will work. Of course, test ahead of time by running your `~/tmp/your-new-sshd -d -p 10022` and ensuring you still can log in.
For cleanliness (not to screw the system even further), as long as that machine still has a functional packaging system - even if package repos are long gone, I would recommend wrapping this binary in a OS-native package format (.deb, .rpm or whatever it uses), making a quick-and-dirty backport (from a custom built static binary), and feeding it to the low-level package manager. Preferably, taking a backup of the original sshd package from the local package cache (or finding that exact same package in some online archive).
I mean, I've put `sshd`s on all sort of embedded systems, Docker containers and whatnot. Even if you have some Gentoo or Slackware machine from early 2000s (or worse), I don't really see much problem in modernizing an SSH daemon there.
The only exception I can imagine is if someone already runs a patched sshd and they can't (or won't risk) backport new stuff in there.