Day 3 - Power trip!
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. 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.
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
YOUR TASKS TODAY
- Change the password of your
- Change the hostname
- Change the timezone
Check out the demo
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.
STOP USING ROOT
If you created a VM with one of the big VPS providers,
root is already “disabled” and your default user (ubuntu, azureuser, etc) already has
Stop using root. If you followed the guides, you should have created a regular user and adding it to a sudoers group, like this:
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
Login with this new user from now on.
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
ls -lto check the permissions of
/etc/shadow- notice that only
roothas any access. Can you use
nanoto 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 cat /etc/shadow
- Test running the
rebootcommand, and then via
Once you’ve reconnected back:
- Use the
uptimecommand 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.
logoutto get back to your own normal “support” login.
lessto view the file
/var/log/auth.log, where any use of
- 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.
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
If you wish to, you can now rename your server. Traditionally you would do this by editing two files,
/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 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:
You might also consider changing the timezone your server uses. By default this is likely to be UTC (i.e. GMT) - which is pretty appropriate for a worldwide fleet of servers. You could also set it to the zone the server is in, or where you and your headquarters are. For a company this is a decision not to be taken lightly, but for now you can simply change as you please!
First check the current setting with:
Then get a a list of available timezones:
And finally select one, like this:
sudo timedatectl set-timezone Australia/Sydney
The major practical effects of this are (1) the timing of scheduled tasks, and (2) the timestamping of the logs files kept under
/var/log. If you make a change, there will naturally be a “jump” in the dates and time recorded.
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
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.
- How To Edit the Sudoers File
- Hardening SSH
- SSH Tunneling
- How To Set Up Multi-Factor Authentication for SSH on Ubuntu 20.04
What’s difference between “sudo -i” and “sudo -s”?
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 -istands 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 -sstands 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.
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.
- This cartoon explains it nicely!
- Sudo in Ubuntu
- How to use “sudo”
- This is how password cracking is done
- Password-less SSH login
Some rights reserved. Check the license terms here