Skip to content

Day 3 - Power trip!

INTRO

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 sudo command.

YOUR TASKS TODAY

  • Change the password of your sudo user
  • 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.

We will get into more detail about users and their permissions on Day 13 and Day 14.

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 sudo powers.

However, if you really, really want to use root, there are ways to do it in AWS, Azure and GCP. But do it at your own risk!

However, if you created a VM locally or with other VPS providers, 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 added 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. Use whoami to print the user name you logged on with.

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. This is specially important if you’re still using root.

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
  • Try cat /etc/shadow, can you view the contents of the file?
  • 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. So it’s safe to assume it shouldn’t be visible to non-authorized users in the system.
  • Now try with sudo, i.e. 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
  • See the login history by filtering the username (e.g. snori74) using the command last. If this is the first time using a non-root user, you will only have one record (i.e. last snori74).
  • Now compare to the times you logged as root: last root
  • Better yet, check for failed login attempts for root with sudo lastb
  • 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 “admin” login.
  • Check the last few times sudo was used by typing: sudo journalctl -e /usr/bin/sudo

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 talk about it in more detail in Day 13.

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 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:

preserve_hostname: true

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:

timedatectl

Then get a a list of available timezones:

timedatectl list-timezones

And finally select one, like this:

sudo timedatectl set-timezone Australia/Sydney

Confirm:

timedatectl

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.

WITH GREAT POWERS COMES GREAT RESPONSIBILITY

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.

Even with that, it’s important to take the necessary precautions before making global changes, to prevent accidentally locking yourself out or other issues. Practices like using a test environment, checking for syntax errors and typos, and keeping an eye on the log files, will eventually become second nature.

EXTENSION

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

Some rights reserved. Check the license terms here

Comments