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?

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

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

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

Solution 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!

Solution 5

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.

View more solutions

Comments

[Dmitry Grigoryev]

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.

[Asklepius M.D.]

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?

[MelodiousFires]

The NoSQL server that I was using is Redis.

[alk]

Just do not work under the root account.

[Admin]

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.

[user428517]

permissions .........

[jmort253]

Not working under root account only works if the passwords are different on different servers. If different servers all have the same passwords, then the wrong system can still be shutdown.

[William]

Ever thought about just... Not executing them?

[isanae]

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.

[TimGJ]

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.

[marcellothearcane]

what about other (arguably more scary) things like rm -rf /?

[Peter - Reinstate Monica]

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

[Brian McCutchon]

You can also use \shutdown instead of /sbin/shutdown to get around the alias (in bash, at least).

[Alex Hall]

@marcellothearcane set -u might help with that in some cases, like when writing rm -rf /$SOME_VARIABLE_WHICH_I_THOUGHT_EXISTS_BUT_DOESNT.

[gronostaj]

source is an alias to . and is not supported by all shells.

[MD XF]

Hm, I used to do this with rm to troll people - alias rm='echo "You can't use rm!" #'

[MelodiousFires]

@TimGJ That is very sensible. I wouldn't recommend disabling most commands. When you want to it is nice to know how, just so long as you use discretion.

[David Richerby]

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.

[rackandboneman]

Try working as root with two or three screens worth of clusterssh, smallest readable font.Then you'll know what scary is.

[Tico]

I'm with @DavidRicherby on this one. Not a good idea.

[Wayne Werner]

@isanae I read recently about someone whose production root shell was a nice 5-line ascii art warning that it was a root terminal on production. I'm a fan of that kind of thing.

[ivan_pozdeev]

sudo it's your turn to get the coffee.

[ivan_pozdeev]

No, it's about "using sudo for everything".

[terdon]

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.

[chepner]

@terdon Aliases aren't inherited by child processes, and they are intended to be used in interactive shells. .bashrc is exactly where they belong. It's a good idea to add something like [[ $- = *i* ]] && source .bashrc to the end of .bash_profile to ensure .bashrc is sourced for interactive login shells.

[Tim]

@isanae I have the .bashrc change the colour of the terminal when I ssh in.

[Jonas Schäfer]

@isanae So much that. I once sat next to someone who accidentally forkbombed a production server while they thought they were using their own machine… That was a slow and painful realisation. And the reason why I have ☢prod☢ in red on the right side of prompts on production servers :)

[Mr Lister]

@TimGJ I don't get how an error message like "you cannot use shutdown" when you type shutdown gets people in the habit of typing shutdown.

[Joe]

@MrLister : The problem is when people get in the habit of expecting hand holding, and they come across a system where it hasn't been done. Decades ago, I worked for our university's main computing center, and we did no such hand-holding. The engineering department had aliased rm to rm -i. So someone came along, and typed rm *, thinking it would prompt them for which files to delete .... and lost everything in that directory.

[TimGJ]

@MrLister The question was about scary commands in general, not shutdown specifically. So I have some across some sites which alias rm ro rm -i. Dumb.

[Barmar]

Wouldn't he have the same problem with sudo shutdown? If he executes it on the wrong machine, it will still be a disaster.

[Attie]

Yes, but at least he's expecting it to work... Running a command like that on "the wrong machine" is a mistake that is trivial to avoid...

[terdon]

@chepner yes, of course they are not inherited and are meant to be used in interactive shells (well, that's tweakable, but never mind). That's no reason to have .bashrc source .profile. There are very good reasons to keep the two separate and I dislike this new trend that has them joined.

[chepner]

You have my suggestion backwards. .bash_profile should source .bashrc. Further, .profile shouldn't be sourcing anything specific to bash.

[user]

@marcellothearcane On anything resembling a modern Linux system, that needs --no-preserve-root which you are unlikely to type by accident.

[Randy L]

who's Molly, I wonder...probably someone's cat.

[CSM]

@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

[Randy L]

@CSM that's some nice computer-nerd anthropology there bud. thanks!

[Hastur]

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

[Ray]

@marcellothearcane That's covered by the "don't run as root" advice, since you'll never run that command intentionally, and are likely to be extra careful when typing anything similar. But sudo shutdown -h now is a perfectly normal thing to type on a laptop and a horrible thing to type on a remote server, so having it check if you are on a remote connection isn't a bad idea.

[Taemyr]

@Barmar Does NoSQL understand the sudo command?

[Barmar]

@Taemyr sudo is a shell command, it has nothing to do with the database.

[Barmar]

@Attie I thought that was the whole point -- he ran shutdown on the server when he intended to run it on the client, because he forgot he was in a ssh shell. He wants to configure something on the server to catch the mistake.

[Attie]

@Barmar - no need - setup a nice prompt like I showed in my answer, then the hostname is in your face. Also, don't run commands like shutdown in a random terminal... make a fresh one - problem solved.

[jpaugh]

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.

[Giacomo Catenazzi]

@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).

[rackandboneman]

Much more annoying is habitually typing "halt" and expecting it to behave like "poweroff" (which it stopped doing on some distributions, eg ubuntu).

[Peter Cordes]

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

[Barmar]

Yes, I see that now. Sorry for the confusion.

[Peter Cordes]

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

[Ruslan]

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

[valbaca]

"Make sure your .bashrc has loaded first," can .bashrc have something like echo "Safety turned on for $scary commands"?

[Dmitry Grigoryev]

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.

[wojciech_rak]

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.

[Kaz]

@Ruslan Nobody who packages this crap into their distro escapes the blame of stupidity.

[Scott - Слава Україні]

If you're going to link to a sudo cartoon, link to the original, definitive sudo cartoon (at xkcd, of course).