On Tue, Jan 19, 2016 at 4:12 PM, Arnt Karlsen <arnt@???> 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.