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.
No comments:
Post a Comment