Day 3 - Power trip!
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.
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
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
(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).
YOUR TASKS TODAY:
- 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 less /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 -iThis 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
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.
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.
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.
- This cartoon explains it nicely!
- Sudo in Ubuntu
- How to use “sudo”
- This is how password cracking is done
Some rights reserved. Check the license terms here