Delays on bad passwords considered harmful, accidental reboot edition

November 24, 2014

Here is what I just did to myself, in transcript form:

$ /bin/su
Password: <type>
['oh, I must have mistyped the password']
[up-arrow CR to repeat the su]
bash# reboot <CR>

Cue my 'oh damn' reaction.

The normal root shell is bash and it had a bash history file with 'reboot' as the most recent command. When my su invocation didn't drop me into a root shell immediately I assumed that I'd fumbled the password and it was forcing a retry delay (as almost all systems are configured to do). These retry delays have trained me so that practically any time su stalls on a normal machine I just repeat the su; in a regular shell session this is through my shell's interactive history mechanism with an up-arrow and a CR, which I can type ahead before the shell prompt reappears (and so I do).

Except this time around su had succeeded and either the machine or the network path to it was slow enough that it had just looked like it had failed, so my 'up-arrow CR' sequence was handled by the just started root bash and was interpreted as 'pull the last command out of history and repeat it'. That last command happened to be a 'reboot', because I'd done that to the machine relatively recently.

(The irony here is that following my own advice I'd turned the delay off on this machine. But we have so many others with the delay on that I've gotten thoroughly trained in what to do on a delay.)

Written on 24 November 2014.
« Using the SSH protocol as a secure transport protocol
My Linux IPSec/VPN setup and requirements »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Nov 24 16:01:43 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.