How to disable scary terminal commands?

Question

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?

Answer 1

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
do
    alias $scary="echo If you really want to do that, type: `which $scary`"
done

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.

Answer 2

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.

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"...

Answer 3

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.

Answer 4

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!

Answer 5

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.

Answer 6

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.

Answer 7

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.

Then

$ 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.

Answer 8

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.

Answer 9

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.