sudoallows you to run a Unix command as a different user. Many beginner users are asking for meaning of the sudo command, so here’s my take.
What sudo does
Using /etc/sudoers file to confirm what privileges are available to you, sudo command effectively elevates your access rights, thus allowing you to run commands and access files which would otherwise be not available to you. sudo runs these commands as root by default.
Apparently, Debian installer doesn’t install or activate sudo by default. This means that sudo command is not found the only privilege escalation method available is becoming root via su command. Since I like and use sudo daily, I decided to install and setup it on Debian VM.
Install sudo package in Debian
That’s the very first step you’ll need to do: use apt to install sudo. You need to become root before you do it, of course (so you must know root user password for your Debian install):
greys@debian:~$ su -
root@debian:~ # apt install sudo
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following NEW packages will be installed:
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,245 kB of archives.
After this operation, 3,886 kB of additional disk space will be used.
Selecting previously unselected package sudo.
(Reading database … 174742 files and directories currently installed.)
Preparing to unpack …/sudo_1.8.27-1_amd64.deb …
Unpacking sudo (1.8.27-1) …
Setting up sudo (1.8.27-1) …
Processing triggers for man-db (2.8.5-2) …
Processing triggers for systemd (241-5) …
root@debian:~ # sudo
usage: sudo -h | -K | -k | -V
usage: sudo -v [-AknS] [-g group] [-h host] [-p prompt] [-u user]
usage: sudo -l [-AknS] [-g group] [-h host] [-p prompt] [-U user] [-u user] [command]
usage: sudo [-AbEHknPS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] [VAR=value] [-i|-s] 
usage: sudo -e [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file …
Configure /etc/sudoers File
/etc/sudoers is the main configuration file for sudo command. It contains list of users and groups that are allowed to become root (or become other users by invoking su command as root).
root@debian:~ # cat /etc/sudoers
# This file MUST be edited with the 'visudo' command as root.
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
# See the man page for details on how to write a sudoers file.
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
I’ve highlighted the 3 most important elements of this file at this early stage:
root ALL=(ALL:ALL) ALL
This is the line that allows you to debug sudo commands as root user.
At this means that any user that belongs to group sudo will also be allowed to use sudo commands:
%sudo ALL=(ALL:ALL) ALL
Finally, this part includes additional configuration files from /etc/sudoers.d directory:
… this means you don’t have to edit /etc/sudoers file but instead can create a specific file in /etc/sudoers.d and name it self-descriptively, like:
meaning, that this file will contain usernames and privileges required by web-server admins (usually commands like stopping/starting Apache or nginx webserver).
Since this is a very basic tutorial, we don’t have to edit the file at all – just need to add our user (mine is greys, as you remember) to the sudo group and check.
Add user to sudo group
Step 1: let’s make sure sudo is not accessible before we begin
This needs to be run as your regular user, not as root:
greys@debian:~$ sudo -i
[sudo] password for greys:
greys is not in the sudoers file. This incident will be reported.
Let’s check my groups just to be sure there’s no sudo among them:
greys@debian:~$ id greys
uid=1000(greys) gid=1000(greys) groups=1000(greys),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(bluetooth),116(scanner)
Step 2: add user to sudo group
Excellent, now it’s time to add user greys to the group sudo (we must become root again to run usermod command)
root@debian:~ # usermod -a -G sudo greys root@debian:~ # id greys uid=1000(greys) gid=1000(greys) groups=1000(greys),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(bluetooth),116(scanner)
As you can see, I’m now a member of the sudo group!
Step 3: Log out and log back in for group membership to be recognised
Now you need to disconnect from your server or desktop session and log in again, so that your group membersip is recognised. One reconnected, check your groups with id command and try sudo again:
uid=1000(greys) gid=1000(greys) groups=1000(greys),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(bluetooth),116(scanner)
so yes, we’re a member of sudo group now… This is the moment of truth! Let’s try to become root:
greys@debian:~$ sudo -i
root@debian:~ # id
uid=0(root) gid=0(root) groups=0(root)
If you’re managing configuration with Puppet or Chef, chances are you’ve heard of Ansible as well.
Just last week we got Ansible 2.0 released which brings quite a few improvents on top of a massive refactoring.
I’m quite late starting with Ansible but very impressed with it so far: it’s a great way of quickly confirming remote server’s state with SSH and sudo AND a neat way of scripting configurations with Ansible playbooks.
I have written my first playbook two weeks ago and need to change them now so that they follow the updated syntax.
Are you guys using Ansible as well?
How to update grub boot loader config
GRUB bootloader starts up what’s necessary for your Linux or UNIX system to boot up. You can edit its settings, like various boot options and which operating systems to select from, by editing the the /boot/grub/grub.cfg or /etc/grub.conf depending on your system. Graphical programs are also available for this purpose. See our GRUB Boot Loader overview for more.
Once you’ve edited your configuration you’ll need to update grub to use it. This is very easily done by this single command:
$ sudo update-grub
Then once you reboot your new config should be active.
Quite recently I came across a very interesting issue: while configuring passwordless SSH (it’s public key based, so depending on you have it configured it may not be completely passwordless) access to some of my VPS servers, I found that the same keypair just wouldn’t work on one of the servers.
Not only that, but the behaviour was quite bizzare: upon my first attempt to connect the public key would get rejected and a regular password would be requested by the ssh session. But once I successfully logged in with my password, any subsequent ssh connections would happily authenticate by my public key and would let me in without a problem.
Those of you using home dir encrypiton in Ubuntu are probably smiling right now! 🙂 But becase I have never consciously configured or used this feature, it took me a good few hours to troubleshoot the issue and come up with the fix.
Why public-key based SSH doesn’t work with encrypted home directories
The answer is quite simple: before your server can decide whether you are providing a valid and trusted SSH key, it must read your public key stored in your homedir. But if your homedir is encrypted, this becomes a classical chicken-and-egg scenario – until you log in and therefore decrypt your homedir the server won’t gain access to your public key. Only you wouldn’t be needing the public key by then, would you?
Store your authorized SSH keys outside your encrypted home directory
If you happen to like your homedir encryption AND would like to use public/private key SSH authentication, there is a way out: you need to store your authorized keys outside of your encrypted homedir.
The usual access restrictions and directory/file permissions still apply, so the only thing you’re changing is moving your authorized keys outside of the encrypted homedir on your server. This way things will work exactly as you expect: you authenticate with your private key and this results in your automatically mounted and decrypted homedir.
Here are the steps to make this happen. You’re going to need superuser privileges for my scenario because it caters for all the users on your Ubuntu server, not just one account that belongs to you (usesudo to become root).
Step 1: create a directory structure for your authorized keys.
First, the main directory, I created it under /var – seems quite a safe choice since this directory is unlikely to grow and is equally unlikely to get removed by accident.
# mkdir /var/openssh
Perfect! Now we need to create user-specific directories, just to keep this dir really tidy. My username is “greys“, so here is the directory: