Has anybody had a good look at the new OpenBSD 'doas' replacement for sudo?
I hope doas will be as easy to set up as they claim, sudo can be a bit
of a pain to setup exactly how you want it.

DaveT

On 19/01/16 21:58, Stephanie Daugherty wrote:
>
> On Tue, Jan 19, 2016 at 4:12 PM, Arnt Karlsen <arnt@???
> <mailto:arnt@iaksess.no>> wrote:
>

>     ..why did Debian kill ssh into localhost?
>     Is su or sudo safer than ssh nowadays?

>
>
>
> Because the architecture of Linux gurantees that root has a fixed
> account name, fixed UID, and, if in a server environment, will be
> essentially a shared account, it's considered a long standing best
> practice to not let people log in directly as root, at least not
> remotely. This makes sure there's an audit trail of logging in with
> the unprivileged user and then elevating to root, rather than just the
> root login that doesn't indicate which of possibly several users was
> responsible. It also means a brute force against the root account is
> more difficult to automate, since you need to attack an umprivledged
> account first, and it offers a little bit of protection against a weak
> root password.
>
> sudo is generally the accepted way in the ubuntu world as well as in
> most server environments these days, since the audit trail will record
> exactly what commands were elevated and by who, and since only a
> single command is run with elevated permissions, therefore dropping
> back to an unprivledged command prompt after each elevated command.
>
> su was the best practice long before sudo or even Linux ever existed,
> and is still perfectly acceptable for hobbyists, desktops, and others
> where there's exactly one *competent* admin for each machine. and may
> even be a viable option in other, more controlled environments that
> don't want to use sudo. Historically, on other *nixes, it was gated
> with the "wheel" group, (and this can be done on Linux as well if the
> admin wants to configure it this way).
>
> Obviously, this has the additional advantage that, through some
> tinkering with PAM, you can implement additional authentication
> requirements just on root access - for example, you might let your
> admins log in and look around with just their SSH key, but require
> them to have an additional password or multifactor authentication
> token to access root privileges.
>
>
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng