Re: Unlocking (remote/local), was Re: Help with suid (bash)
On Wed 11 May 2022 at 20:26:20 (+0200), tomas@tuxteam.de wrote:
> On Wed, May 11, 2022 at 11:07:09AM -0500, David Wright wrote:
>
> [...]
>
> > But after two posts about background information on setuid shell
> > scripts, you now write "the worst antipattern is to misuse tech
> > to force people to follow some nonsensical rituals". Strong words.
>
> Sorry if I was unclear. The point I was trying to make is that
> OpenSSH allows you to change the behaviour we are discussing
> if you wish so. So it /doesn't/ follow that antipattern.
I don't know what the antipattern is, that openssh doesn't follow.
> As to the other points? Well:
>
> 0. if you want to be able to login directly as root, /and/
> with a password, change the server's /etc/sshd_config
Perhaps I need to make it clear that:
. I have set a password for root.
. I can login as root at the console, using that password.
. I do not want to login as root by password from any other
system, be it mine or anyone else's.
. I do not want to force, persuade, or hint that anyone else
should follow my preferences.
> 1. if you can be bothered to set up a key for root, use
> that (generally preferrable to 0.)
I have. On all my systems, root can login as root, by key,
on any other of my systems. And the same for me as me. Other
users (which includes me) aren't set up to login by key or
password to the root account: they use su.
(Or avoid login with sudo.)
The recipe I posted for the OP doesn't mention or use keys,
or use the root account. The secondary script (unlock-…)
that I use to run the main one does use ssh, but is silent on
the authentication method.
Charles suggested that the OP just run things as root. As
I was posting a script that's really designed for remote
unlocking, I thought it helpful to point out that in an
unaltered Debian system, you wouldn't be able to login as
root. (I see no reason against basing answers on a vanilla
Debian stable system.)
> 1a. you can even limit what a private key owner is able to
> do: e.g. "only backup". So even if someone manages to
> steal your remote backup's private key, (s)he'll only
> able to trigger a backup
I didn't read the OP's question as necessitating that sort of
configuration. Anyone who thinks to the contrary is free to
add their own reply.
> 2. if you don't like 0..1a, there's still sudo. You can
> fine-tune what commands (and what parameters go with
> those) each (local or remote) user is allowed to invoke,
> and even whether they're supposed to issue a password
> for that or they get it "password-less".
Isn't that what I did: I spelled out the exact limitations
that I impose, with the actual lines from the sudoers file,
complete with their parameters and partial values, including
the fact that after quoting (or not) the password to log in,
they're not expected to quote it again just for sudo.
> What's not to like?
I don't know. I posted a script that does more than what the OP
wanted to achieve (which was to avoid using the root account),
and because it's a real script, I tried to add any information
that explained specifics that might not be immediately understood,
like:
. why it's in .profile,
. what /home/0 is,
. why it prints a line between unlocking and mounting,
. who unlock is,
. why unlocking a system remotely might be attractive,
. why lines were added to the sudoers file.
> What's missing?
Evidently, a discussion on becoming root.
And if you're following along closely, and ignore the likely
circumstances of my script being run, you might point out that
there's no obvious way for user unlock to unmount or lock /home.
Cheers,
David.
Reply to: