How do you disable scary terminal commands?

I was using SSH to access a remote Ubuntu server without access to the physical server. I thought I was typing 'shutdown' into the NoSQL server running on the Ubuntu OS, but actually I told the Ubuntu server to shutdown. Then I had to tell the server admin what I did so that he could start up the physical server for me. That was embarrassing!

How can I keep this from happening again?

  • 102
    This has been discussed in lengths, usually with relation to rm which has worse side effects than shutdown. Bottom line: here is no way to prevent bad things from happening if you keep running random commands as root. Jun 19, 2017 at 10:17
  • 5
    As other people have noted regarding aliasing, doing so can make people "get in the habit of a command working in a non-standard way." So does it seem bad to anyone else that the silly NoSQL server uses this command?
    – bmb
    Jun 19, 2017 at 23:08
  • The NoSQL server that I was using is Redis. Jun 19, 2017 at 23:25
  • 61
    Just do not work under the root account.
    – alk
    Jun 20, 2017 at 8:38
  • 12
    I dare say you learnt the lesson so won't have to feel the need to disable any command again. I'd also add you don't fool-proof GNU/Linux, you just get better than the fool.
    – user463678
    Jun 20, 2017 at 14:13

9 Answers 9


The standard answer is "don't login as root". All commands run as root are scary. If that isn't an option you could put some alias commands into your .bashrc to disable commands you find especially scary. For example:

for scary in shutdown halt  reboot rm
    alias $scary="echo If you really want to do that, type: `which $scary`"

Then, if you type shutdown you will get the following message:

If you really want to do that, type: /sbin/shutdown

(Make sure your .bashrc has loaded first, before you try this on a production server)

Quitting your current ssh session and logging in again, or using . ~/.bashrc should load/run .bashrc. Perhaps try running rm without any arguments to make sure your server hasn't disabled automatically loading .bashrc on logins or similar.

Note that if you are primarily concerned with halt and shutdown, you could consider installing molly-guard, which will make you type the hostname before shutting down the machine. This is more useful if you regularly shutdown whole OS'es on the commandline, but want to make sure you are shutting down the right one.

You could also test try this with a less scary command such as logout or exit.

  • 70
    don't login as root: this won't help if you're confusing the machine you're logged into. I'd suggest changing the prompt to something that would give you a visual cue.
    – isanae
    Jun 18, 2017 at 15:40
  • 145
    Aliasing "scary" commands to have a "safe" behaviour is, in my experience, a bad idea. This is because people tend to get in the habit of a command working in a non-standard way which can make them do some very regrettable things when they are on a vanilla system. Simple answer is to tread very carefully when logged in as root.
    – TimGJ
    Jun 18, 2017 at 17:46
  • 22
    @isanae The shortcut I used to open a terminal with ssh to the production server would make the terminal background light red. That made me pay attention. Jun 18, 2017 at 20:47
  • 6
    source is an alias to . and is not supported by all shells.
    – gronostaj
    Jun 18, 2017 at 23:57
  • 4
    Also note that while Debian and, by extension, Ubuntu have the defaullt ~/.bash_profile source .bashrc, that isn't standard behavior and on most systems, .bashrc is not read when logging in via ssh, so this won't make a difference there. It is far better to add the aliases to ~/.profile or ~/.bash_profile instead.
    – terdon
    Jun 19, 2017 at 16:34

sudo exists for a reason - use it. When your command (in this case an interactive CLI) is finished, you're dumped back to your user-level shell, not a root shell. There are very few worthy reasons to be in a root shell. (I'm surprised that this isn't already an answer...)

Having said that, don't be a muppet that uses sudo for everything. Understand what you're doing, and understand why it does/doesn't require root privileges.

Additionally you can differentiate your prompt for root / user shells. This also makes it more obvious that you're back at the shell prompt and not "some other CLI". Mine is very colorful, and has lots of useful information (such as the hostname), which makes it very simple to know what host the command will execute on, and also makes it easier to look back through your history and locate prompts - a root shell uses the default prompt.

My PS1

This is more suitable to use on "your" account, but if you're taking security/sysadminning seriously, then you won't be sharing passwords/accounts, and you won't be sitting in a root shell without being fully aware.

As people have said over, and over, and over again "aliasing commands to make a safe environment is a bad idea". You're going to get comfortable in your safe environment, typing those 'scary' commands where you shouldn't. Then one day you'll change jobs, or login to a new machine, and then boom "whoopsy, I didn't mean to, I'm sorry"...

  • 7
  • 2
    Wouldn't he have the same problem with sudo shutdown? If he executes it on the wrong machine, it will still be a disaster.
    – Barmar
    Jun 20, 2017 at 16:08
  • 2
    @Barmar Does NoSQL understand the sudo command?
    – Taemyr
    Jun 22, 2017 at 9:09
  • 2
    @Taemyr sudo is a shell command, it has nothing to do with the database.
    – Barmar
    Jun 22, 2017 at 15:22
  • 4
    @Barmar: Actually I think the OP meant to type it into a NoSQL cmdline program, not into bash. So they wouldn't have typed sudo shutdown, since I assume sudo isn't a NoSQL command. Not being in a root shell would have totally solved that problem and been a very good idea. So would looking at the prompt carefully before running important commands. Jun 23, 2017 at 18:32

The package 'molly-guard' (at least on Debian derived systems) will install a wrapper around shutdown, halt, poweroff, and reboot. If it detects that the terminal is a remote one, then it will prompt for the host's name. If it doesn't match, then the command is cancelled.

  • 4
    what about other (arguably more scary) things like rm -rf /? Jun 18, 2017 at 20:43
  • 9
    @marcellothearcane set -u might help with that in some cases, like when writing rm -rf /$SOME_VARIABLE_WHICH_I_THOUGHT_EXISTS_BUT_DOESNT.
    – Alex Hall
    Jun 18, 2017 at 22:19
  • 4
    @marcellothearcane On anything resembling a modern Linux system, that needs --no-preserve-root which you are unlikely to type by accident.
    – user
    Jun 21, 2017 at 13:49
  • 3
    who's Molly, I wonder...probably someone's cat.
    – Randy L
    Jun 21, 2017 at 19:40
  • 7
    @the0ther, a 2 year old kid, who triggered the SCRAM switch on a dinosaur machine, twice in the same day. They folks in the room rigged a cover on the switch. catb.org/jargon/html/M/molly-guard.html
    – CSM
    Jun 21, 2017 at 19:47

I accepted an answer that I like a lot, however, if anyone else is reading and want a simpler answer, here is mine.

Find the .bashrc file and put as the last line:

alias shutdown=notforuse

Then when you type shutdown you get something like ~bash: notforuse is not a command

This might be silly but it is simple and it works. I do appreciate answers with better ways to do this however!

  • 4
    Hm, I used to do this with rm to troll people - alias rm='echo "You can't use rm!" #'
    – MD XF
    Jun 19, 2017 at 1:33
  • 53
    I think this is a bad idea, for three reasons. First, it's confusing for anybody else who has root access to the machine. Second, it trains you that it's OK to type "shutdown" and hit enter, which means you're likely to make the same mistake on the next system you have root access to. Third, this will become extremely confusing if there's ever a valid command called notforuse on the path. Jun 19, 2017 at 7:14
  • 5
    I'm with @DavidRicherby on this one. Not a good idea.
    – trinaldi
    Jun 19, 2017 at 11:15
  • If you really want to use the aliases, you can at least put all those scaring command aliases in a file, let we say ~/.SaveMyReputation and add as last line of your .bashrc a line as [ -f ~/.SaveMyReputation ] && source ~/,SaveMyReputation. You may want eventually to add an extra line echo "#Scaring command protected shell, comment the last line of .bashrc and log again to have a full working shell" inside that file. At least you may bring with you this alias file on other machine (it should be .bash_aliases, but in this "deprecated" case is better to use another name).
    – Hastur
    Jun 21, 2017 at 21:37
  • If you're going to do this, make it less confusing by using a name like alias shutdown=shutdown-disabled-by-an-alias. (This only addresses the 3rd and most minor problem that @DavidRicherby pointed out.) Although it will still probably only take 2 seconds for the next person to go from seeing notforuse is not a command to running type -a shutdown and finding the alias, then typing sudo \shutdown to disable alias expansion. (Assuming they had sudo aliased to sudo='sudo ' so it expands aliases in its first arg). Jun 23, 2017 at 18:37

For shutdown (reboot, halt and related): I have a copy with ask me if I'm really sure (and it does nothing anyway). I store such scripts in in /usr/local/sbin. On Debian this has priority other /sbin (it is the first directory of PATH).

System scripts use full path, so such hack prevent me to stopping a remote server instead of local machine (a bad behaviour from Awesome WM), but has not other indirect effect, and I can still use them as /sbin/shutdown when really needed.

  • Such hacks only work if you apply them to every computer you ever log in to... that is often quite impractical, and you won't find out until it's too late: by typing shutdown on a critical system which does not have your hack.
    – jpaugh
    Jun 23, 2017 at 1:38
  • @jpaugh: yeah, it is an hack, and I use it only for my personal servers, where I often logged in, and terminals remain open for too much time. [Note: I use also different color prompts for my personal machines: remote-root, remote-user, local-root, local-user]. For real servers and remote machine, I avoid root and I go root as little as possible, and for sure, without forgetting to exit from them. Just I'm using the my remotes as "cloud" (before the cloud hype, so handled on the old way). Jun 23, 2017 at 8:19

The Sudoers file allows a much finer level of granularity than just * 'is allowed to use sudo'*, in particular you can use command aliases to create white lists of groups of commands a particular user or group is restricted to. I have worked with remote servers that were restricted to ssh access and allowed password-less sudo (we did require password protected ssh keys). There are some good reasons for doing this, but it does have dangers, so we used command aliases to allow unrestricted access to things they need to do (restarting servers etc) without granting them privileges for thing they didn't.

There is also syntax to say 'can't run this command'. It can be worked around, so it shouldn't be used as a real security measure but it would work for the scenario you described.

Man sudoers has some good examples on how to set this all up.

Of course this requires using sudo, but that should go without saying.


You may have fallen victim to some new Ubuntu stupidity.

Ubuntu used to have the normal, classic shutdown command which takes a mandatory time argument.

Here is what happens on Ubuntu 12 if I type shutdown, even as a regular user:

$ shutdown
shutdown: time expected
Try `shutdown --help' for more information.


$ shutdown +100
shutdown: need to be root.

Now, here is Ubuntu 16.10. I'm not root:

$ date ; /sbin/shutdown
Fri Jun 23 16:00:16 PDT 2017
Shutdown scheduled for Fri 2017-06-23 16:01:16 PDT, use 'shutdown -c' to   cancel.

With no arguments, it schedules a shutdown for 60 seconds later, and even if you're not root—just an account made with admin privileges.

Blame Canonical.

  • 8
    /sbin/shutdown is provided by systemd-sysv package by default, so it's not Ubuntu stupidity, it's systemd stupidity, and it comes not from Ubuntu, but from Debian at least, which, in turn, seems to take the whole systemd movement from Red Hat. When blaming, blame the correct entity — not just the one you dislike.
    – Ruslan
    Jun 24, 2017 at 6:45
  • 1
    @Ruslan Nobody who packages this crap into their distro escapes the blame of stupidity.
    – Kaz
    Jun 29, 2017 at 12:42

For shutdown there is molly-guard. You just need to install it and when you try to shutdown via ssh, it asks you to type the hostname.

For deleting files there are solutions like libtrash, which emulates a trash bin via a LD_PRELOAD library.

And you can test what files you're changing/deleting/... with the maybe program. That's pretty cool when testing something.

  • 1
    This maybe thing seems to be broken by design: stubbing some syscalls with no-ops is going to crash any non-trivial program which relies on these syscalls to succeed. Jun 26, 2017 at 8:41

Try this: when you are on a remote shell, every time you are about to type the "return" key, stop for 5 seconds, with your finger hovering on the "return" key, and reread the command you are about to send. Is it OK? Are you sure?

This seems harsh, but, on the other hand, we shouldn't be spending a lot of time on remote shells. We should find all ways to automate our maintenance work so that we rarely, if ever, need to log in to a remote server at all.

  • 1
    Tried that, not working. I entered shutdown, stopped for 5 seconds, reread command (aloud!) and I am sure it was correct. Then hit enter and the command just executed. So that didn't disable scary commands, I'm afraid. I will try with this finger hovering thing, maybe the distance was too small/large. Jun 28, 2017 at 6:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .