On 23/02/28 16:17, Erling Westenvik wrote: > Thanks. And I "know".. > > Use case: sshd in single user on quasi FDE-encrypted servers on co-location > not > accessible via KVM/AMT. I've done this on many machines since 2014. > > I acknowledge that it isn't recommended practice (and definitely not > supported!) but if anyone should want to help out, feel free to contact me > off-list! > > Best regards > > Erling
(Keeping this on-list for the archives so anyone with a similar idea is aware of the consequences before attempting it. I hope you understand) I mean this in the kindest way: this sounds a lot like the "XY Problem." From what I can tell, you're presupposing that X (a statically linked and more vulnerable sshd) is the most appropriate way to handle Y (accessing single-user mode on those servers). It tends to be much more helpful to ask directly about Y. So it's OK, and even preferable, to focus on asking about Y, providing X as an explanation of what you've tried when prompted for it or if it seems appropriate to include. In any case, I can't speak much to how to do X here because I've never dealt with opening up single-user to remote login. In fact, I'd actually do whatever I could to find a different way of handling this. I'll explain why briefly. As you probably already know, single-user gives an exceptional level of control over system internals that are normally unavailable for security reasons---even root in multi-user is prohibited from doing these things. Its use is therefore best reserved for exceptional circumstances. It also follows that you should log in to single-user mode over a physical connection rather than a remote one if at all feasible, as an unauthorized party gaining this level of access is "game over" (this sort of thing is an attacker's fantasy, to say the least...). To sum it all up, what you're trying to do is hazardous and likely to end poorly. That's why it's unsupported.
