On Tue, Jan 19, 2016 at 4:12 PM, Arnt Karlsen <a...@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@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
