more about sudo

docs/03.md

@@ -1,39 +1,89 @@
 # Day 3 - Power trip!
 
-* [Complementary video](https://youtu.be/B6fDvmmh2_Q)
+* [Lesson video](https://youtu.be/B6fDvmmh2_Q)
 
 ## INTRO
 
-You've been logging in as an ordinary user at your server, yet you're probably aware that `root` is the power user on a Linux system. This administrative or "superuser" account, is all powerful - and a typo in a command could potentially cripple your server. As a sysadmin you're typically working on systems that are both important and remote, so avoiding such mistakes is A Very Good Idea.
+You may have been logging in as an ordinary user at your server, yet you're probably aware that [root is the power user on a Linux system](https://www.ssh.com/academy/pam/root-user-account#what-is-a-root-user?). This administrative or "superuser" account, is all powerful - and a typo in a command could potentially cripple your server. As a sysadmin you're typically working on systems that are both important and remote, so avoiding such mistakes is *A Very Good Idea*.
 
-On many older production systems all sysadmins login as “root”, but it’s now common Best Practice to discourage or disallow login directly by `root` - and instead to give specified trusted users the permission to run root-only commands via the `sudo` command.
+In ancient times, sysadmins used to login as `root` in production systems, but it’s now common Best Practice to discourage or disallow login directly by `root` and instead to give specified trusted users the permission to run root-only commands via the `sudo` command.
 
-This is the way that your server has been set-up, with your “ordinary” login given the ability to run any root-only command  - but only if you precede it with `sudo`.
+## YOUR TASKS TODAY
 
-(Normally on an Ubuntu system this will ask you to re-confirm your identity with your password.
-However, the standard AWS Ubuntu Server image does `not` prompt for a password).
+* Change the password of your `sudo` user
+* Change the hostname
+* Change the timezone
 
-## YOUR TASKS TODAY:
+Check out the [demo](https://asciinema.org/a/619818)
+
+## LOCAL CHANGES VS GLOBAL CHANGES
+
+**Global**: programs/environments that any user can use, used across the system. A global change affects all users.
+**Local** or **By user**: programs/environments that a particular user runs, not available to other users. A local change affects only one user.
+
+## WHO ARE YOU AND WHAT CAN YOU DO?
+
+There are 3 types of users in a Linux system:
+
+* `root` - the powerful superuser that can execute any command at any level in the system. They can do all global changes as well as local changes for any user.
+* `sudoers` - regular users that are allowed to use `sudo`, i.e., they can execute commands in one or more levels in the system, can do some or all global changes. It's common to have at least one sudoer that has the same powers as root, but the amount of priviledges other sudoers have can vary.
+* `regular users` - users that can use the system but can only do local changes, i.e., can only deal with their own files/directories and environment variables.
+
+We will get into more detail about users and their permissions on [Day 13](https://linuxupskillchallenge.org/13/) and [Day 14](https://linuxupskillchallenge.org/14/).
+
+## STOP USING ROOT
+
+If you created a VM with [one of the big VPS providers](https://linuxupskillchallenge.org/00-VPS-big/), `root` is already "disabled" and your default user (ubuntu, azureuser, etc) already has `sudo` powers.
+
+However, if you really, *really* want to use `root`, there are ways to do it in [AWS](https://tecadmin.net/how-to-enable-ssh-as-root-on-aws-ubuntu-instance/), [Azure](https://stackoverflow.com/questions/24313562/root-login-ubuntu-vm-on-azure) and [GCP](https://cloud.google.com/compute/docs/connect/root-ssh). **But do it at your own risk!**
+
+However, if you created a VM [locally](https://linuxupskillchallenge.org/00-Local-Server/) or with [other VPS providers](https://linuxupskillchallenge.org/00-VPS-small/), it is very likely that you have your `root` user readily available.
+
+Stop using root. If you followed the guides, you should have created a regular user and adding it to a sudoers group, like this:
+
+`adduser snori74`
+
+`usermod -a -G sudo snori74`
+
+Adding a regular user to a group with `sudo` priviledges is the easiest way to do it, as the `sudo` group is pretty standard in Ubuntu. But this can also be accomplished by modifying the `/etc/sudoers` using the command `visudo`.
+
+Login with this new user from now on.
+
+## CHANGE PASSWORD
+
+If you're using a password to login (rather than public key), then now is a good time to ensure that this is very strong and unique - i.e. at least 10 alphanumeric characters - because your server is fully exposed to bots that will be continuously attempting to break in. Use the `passwd` command to change your password. To do this, think of a new, secure password, then simply type `passwd`, press “Enter” and give your current password when prompted, then the new one you've chosen, confirm it  - and then WRITE IT DOWN somewhere. In a production system of course, public keys and/or two factor authentication would be more appropriate.
+
+## A NOTE ON "HARDENING"
+
+Your server is protected by the fact that its security updates are up to date, and that you've set *Long Strong Unique* passwords - or are using public keys. While exposed to the world, and very likely under continuous attack, it should be perfectly secure. Next week we'll look at how we can view those attacks, but for now it's simply important to state that while it's OK to read up on "SSH hardening", things such as changing the default port and `fail2ban` are unnecessary and unhelpful when we're trying to learn - and you are perfectly safe without them.
+
+## THE POWER OF SUDO
 
 * Use the links in the "Resources" section below to understand how `sudo` works
 * Use `ls -l` to check the permissions of `/etc/shadow` - notice that only `root` has any access. Can you use `cat`, `less` or `nano` to view it?
 * This file is where the hashed passwords are kept. It is a prime target for intruders - who aim to grab it and use offline password crackers to discover the passwords.
-* Now try with `sudo`, e.g. `sudo less /etc/shadow`
+* Now try with `sudo`, e.g. `sudo cat /etc/shadow`
 * Test running the `reboot` command, and then via `sudo` (i.e. `sudo reboot`)
 
 Once you've reconnected back:
 
 * Use the `uptime` command to confirm that your server did actually fully restart
-* Test fully “becoming root” by the command `sudo -i`  This can be handy if you have a series of commands to do "as root". Note the change to your prompt.
+* Test fully “becoming root” by the command `sudo -i`. This can be handy if you have a series of commands to do "as root". Note the change to your prompt.
 * Type `exit` or `logout` to get back to your own normal “support” login.
 * Use `less` to view the file `/var/log/auth.log`, where any use of `sudo` is logged
 * You could "filter" this by typing: `grep "sudo" /var/log/auth.log`
 
+*Normally invoking the `sudo` command will ask you to re-confirm your identity with your password. However, this can be changed in the sudoers configuration file so it does NOT prompt for a password.*
+
+## ADMINISTRATIVE TASKS
+
+We will go into detail of the many things you can do to your server, but here are some examples of simple administrative tasks that require `sudo`.
+
 If you wish to, you can now rename your server. Traditionally you would do this by editing two files, `/etc/hostname` and `/etc/hosts` and then rebooting - but the more modern, and recommended, way is to use the `hostnamectl` command; like this:
 
 `sudo hostnamectl set-hostname mylittlecloudbox`
 
-No reboot is required.
+No reboot is required but if you want to see the new name in the prompt, just open a new session with `bash` (or logoff and login again, same effect).
 
 For a cloud server, you might find that the hostname changes after a reboot. To prevent this, edit `/etc/cloud/cloud.cfg` and change the "preserve_hostname" line to read:
 
@@ -63,23 +113,31 @@ The major practical effects of this are (1) the timing of scheduled tasks, and (
 
 As a Linux sysadmin you may be working on client or custom systems where you have little control, and many of these will default to doing everything as `root`. You need to be able to safely work on such systems - where your only protection is to double check before pressing `Enter`.
 
-On the other hand, for any systems where you have full control, setting up a "normal" account for yourself (and any co-admins) with permission to run `sudo`  is recommended. While this is standard with Ubuntu, it's also easy to configure with other  popular server distros such as Debian, CentOS and RHEL.
-
-## A NOTE ON "HARDENING"
-
-Your server is protected by the fact that its security updates are up to date, and that you've set Long Strong Unique passwords - or are using public keys. While exposed to the world, and very likely under continuous attack, it should be perfectly secure. Next week we'll look at how we can view those attacks, but for now it's simply important to state that while it's OK to read up on "SSH hardening", things such as changing the default port and `fail2ban` are unnecessary and unhelpful when we're trying to learn - and you are perfectly safe without them.
+On the other hand, for any systems where you have full control, setting up a "normal" account for yourself (and any co-admins) with permission to run `sudo` is recommended. While this is standard with Ubuntu, it's also easy to configure with other popular server distros such as Debian, CentOS and RHEL.
 
 ## EXTENSION
 
+* [How To Edit the Sudoers File](https://www.digitalocean.com/community/tutorials/how-to-edit-the-sudoers-file)
 * [Hardening SSH](https://medium.com/@jasonrigden/hardening-ssh-1bcb99cd4cef)
+* [SSH Tunneling](https://linuxize.com/post/how-to-setup-ssh-tunneling/)
 * [How To Set Up Multi-Factor Authentication for SSH on Ubuntu 20.04](https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-20-04)
 
+### What's difference between "sudo -i" and "sudo -s"?
+
+Both `sudo -i` and `sudo -s` are commands that allow a user to obtain root privileges on a Unix-based system. However, they have some differences in how they function.
+
+* `sudo -i` stands for "sudo interactive" and it launches a new login shell for the root user. This means that it creates a new environment for the root user with the root user's home directory and shell configuration files. This makes it similar to logging in directly as the root user, and any commands executed from this shell will have the privileges of the root user.
+* `sudo -s` stands for "sudo shell" and it launches a new shell for the root user, but it does not create a new login shell. This means that it does not change the environment or shell configuration files of the current user. Any commands executed from this shell will have the privileges of the root user, but the environment will still be that of the current user.
+
+In summary, `sudo -i` is more powerful and creates a new shell with the full environment of the root user, while `sudo -s` is less powerful and only launches a new shell with the root user's privileges but with the same environment as the current user.
+
 ## RESOURCES
 
 * [This cartoon explains it nicely!](http://xkcd.com/149/)
 * [Sudo in Ubuntu](https://help.ubuntu.com/community/RootSudo)
 * [How to use "sudo"](https://www.howtoforge.com/tutorial/sudo-beginners-guide/)
 * [This is how password cracking is done](https://null-byte.wonderhowto.com/how-to/crack-shadow-hashes-after-getting-root-linux-system-0186386/)
+* [Password-less SSH login](https://linuxize.com/post/how-to-setup-passwordless-ssh-login/)
 
 Some rights reserved. Check the license terms
 [here](https://github.com/livialima/linuxupskillchallenge/blob/master/LICENSE)