Customize the sudo Lecture (the Warning Message)

You change the sudo lecture file with two Defaults lines in sudoers. Run visudo and add:

Defaults lecture = always
Defaults lecture_file = /etc/sudo_lecture

Then put your warning text in /etc/sudo_lecture. The next time anyone runs a sudo command, they read your message instead of the stock "We trust you have received the usual lecture" speech. That is the whole feature. The rest of this post is the parts that bite you: where the file lives, when the lecture actually fires, and why you should never hand-edit sudoers without visudo.

The default lecture, and where it comes from

The lecture defaults to once, so you have almost certainly seen it: the first time you ever ran sudo on a box, before your first password prompt, sudo printed the built-in text. It only shows once per user, so it is easy to forget. The text reads:

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

That string is compiled into sudo itself. You do not edit a file to change it; you override it by pointing lecture_file at your own text. The lecture option controls whether and how often it shows; lecture_file controls what it says.

Turn it on with visudo

Never open /etc/sudoers in a plain editor. A syntax error in that file can lock every user, including root, out of sudo. Use visudo, which parses the file before saving and refuses to write a broken one. The full reasoning is in editing sudoers the safe way with visudo, but the short version: visudo is the only correct way to touch sudo config.

sudo visudo

Add these two lines (order does not matter, but keep Defaults lines together near the top):

Defaults lecture = always
Defaults lecture_file = "/etc/sudo_lecture"

Save and exit. If you typed something visudo does not like, it stops and offers to re-edit rather than committing the mistake. That guard is the entire reason the tool exists.

Write the message

The lecture_file is a plain text file. Create it as root and write whatever you want users to see:

sudo tee /etc/sudo_lecture >/dev/null <<'EOF'
========================================================
  This is a production server. Every sudo command is
  logged with your username, the command, and a timestamp.

  Think before you type. If you are not certain, stop and ask.
========================================================
EOF

Now trigger it. With lecture = always it fires on every command; if you switched to once and have already seen it this session, clear the cached state first to force it again:

sudo -k        # forget the cached credential and lecture state
sudo whoami

What that produces:

========================================================
  This is a production server. Every sudo command is
  logged with your username, the command, and a timestamp.

  Think before you type. If you are not certain, stop and ask.
========================================================
[sudo] password for techearl:
root

The lecture is printed to standard error, before the password prompt, not after. That ordering matters: it is a warning the user reads before authenticating, not a receipt after the fact.

Controlling when the lecture shows: the lecture option

lecture_file is only half of it. The lecture Defaults option decides the frequency, and it takes one of three values:

So the common setup is to leave lecture at its once default (or set it explicitly) for a message people see on their first sudo, or set Defaults lecture = always for a compliance banner you want in front of every command. Because the default is once, setting lecture_file alone is enough to replace the text the user sees, but be explicit and set both if you also want to change the frequency.

The "once" state is stored alongside the credential timestamp (under /run/sudo/ts/<user> on most modern Linux). sudo -k resets it, which is why I used sudo -k above to re-test. A reboot clears /run too, so "once" really means "once per timestamp lifetime", not "once forever".

A worked example: a per-user reminder

Say I want every developer to see a short reminder the first time they reach for sudo each session, but I do not want to nag them on every command. visudo:

Defaults lecture = once
Defaults lecture_file = "/etc/sudo_lecture"

/etc/sudo_lecture:

You are about to run a command as root. On this box that means:
  - the change is logged and attributed to you
  - there is no undo for rm, dd, or a bad redirect
Proceed deliberately.

First sudo of the session prints the reminder and asks for the password. Every sudo after that, within the timestamp window, just asks for the password (or nothing, if the timestamp is still valid). That is usually the behavior you actually want: a nudge, not a wall of text on every line.

Caveats and distro differences

A few things that trip people up:

• The lecture is not a security control. It is a notice. Anyone with sudo rights still runs the command; the lecture cannot deny anything. If you want to restrict what a user can run, that is a Cmnd_Alias and a command spec in sudoers, not a lecture. See how to give sudo access on Linux for the access side.
• It only fires when sudo prompts. If a user has passwordless sudo via NOPASSWD, sudo still runs the lecture logic, but the experience differs and an always lecture in front of every NOPASSWD command gets old fast. Test your exact config.
• lecture_file must be readable by sudo at run time. Keep it root-owned and world-readable (chmod 644 /etc/sudo_lecture). If sudo cannot open the file, it silently falls back to the built-in lecture text.
• The contents print verbatim to the terminal. sudo writes the file straight to standard error, so ANSI escape codes work: you can color the banner or run it through figlet/toilet for a big header. That cuts both ways. Because the bytes are emitted raw, only root should be able to write the file (the chmod 644 above keeps it root-owned), or someone who can edit it could plant terminal-control escape sequences that fire on every sudo.
• lecture is also a negatable flag. Beyond the once/always/never keywords, you can write Defaults !lecture, which resolves to never, and a bare Defaults lecture implies once. Every current Linux distribution ships a sudo that understands the three-value form; check with sudo --version if you are on something unusual.
• Defaults placement. Put these on their own Defaults lines. You can also scope a lecture to a specific user or host with Defaults:username or Defaults@host, but the global form above is what you want for a server banner.

When not to bother

If your goal is an audit trail, the lecture is the wrong tool: sudo already logs every command to syslog (or the journal), and that log is what an auditor reads, not a banner nobody screenshots. If your goal is a legal "authorized use only" notice at login, that belongs in /etc/issue and the SSH banner, which every connection sees, not just sudo users. The sudo lecture earns its place in exactly one spot: a short, in-context reminder at the moment someone reaches for root, where it is most likely to actually change behavior.

See also

• Editing sudoers safely with visudo: the syntax-checked way to make every change in this post, and why a plain editor can lock you out.
• How to give sudo access on Linux: granting and scoping root privileges, including limiting a user to specific commands.
• Passwordless sudo on Linux: the NOPASSWD tag and how it changes when the lecture and password prompt fire.