Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have remote ssh access and root access. I do not have physical access. I'm not looking for solutions involving booting into anything, I want to do this from what is currently running.

OS is SL6. Is there a way to load everything needed into RAM, and use dd or similar to securely wipe the entire disk? Obviously this will result in a non-functioning box in the end, my intended result.

It seems like this should be possible.

Two more interesting additions:

  1. Be able to ssh in, run screen, run the dd command and detach. Log in a week later once it has finished. :)

  2. Somehow have a progress bar?

Update: I am now going with the chroot option. Currently doing:

mkdir /dev/shm/ramdisk/ && cd ramdisk && mkdir bin lib64 && cd /lib64 && cp /dev/shm/ramdisk/lib64 && cd /bin && cp bash dd /dev/shm/ramdisk/bin && cd /dev/shm/ramdisk && chroot .

Which works(!) but I still need /dev/zero and /dev/sda. Any ideas there?

Update 2012-07-20:

mkdir /dev/shm/ramdisk/ && cd /dev/shm/ramdisk && mkdir bin lib64 && cd /lib64 && cp /dev/shm/ramdisk/lib64 && cd /bin && cp bash dd /dev/shm/ramdisk/bin && mkdir /dev/shm/ramdisk/dev && cd /dev/shm/ramdisk/dev && cp -a /dev/zero . && cp -a /dev/sda . && cd .. && chroot . dd if=/dev/zero of=/dev/sda bs=1M

Which appears to be doing something, but I would like to have some sort of progress indicator if possible, as well as a way to detach and then establish a new ssh connection later.

share|improve this question
Try it ;) Eventually in a VM first. – Frederik Nielsen Jul 17 '12 at 19:16
When you say booting is not an option, are you saying that touching the console/inserting media is not an option, or that the machine cannot be rebooted at all? Because you potentially could add a livecd image on your disk. When the system reboots it boots the livecd image, loads to memory and starts an SSH server. – Zoredache Jul 17 '12 at 19:18
Indeed, I have no physical access. At any rate, I am aware of the live cd solution, so I am interested in learning another solution, specifically with the conditions posed in this problem. Thanks!! – cat pants Jul 17 '12 at 19:23
Pure speculation: I wonder if chrooting into a RAMdisk may help with this. Second speculation: partition a part of the drive, rewrite grub, and reboot. – Hyppy Jul 17 '12 at 19:47
There is only one secure option, if data confidentiality is truly a concern: you must destroy the disk. Normal options are: 1) degausser, 2) disk sander, 3) ball peen hammer. If you can reboot, then there is an option to run some DoD-level disk-wipe tools but you have eliminated reboots as an option. – Mike Pennington Jul 18 '12 at 22:20

Create an image in a ramdisk containing whatever tools you require to nuke the system, then pivot_root into it, run the tool, away you go. Pivoting out of a full system isn't trivial, but it can be done if you know what you're doing.

share|improve this answer
That's a cool idea. So the question then becomes: what is the bare minimum for me to throw into a ram disk to be able to accomplish this? Let me try and figure that out on my own, then I will either comment on here or post a new thread if I can't figure it out. Thanks! – cat pants Jul 18 '12 at 0:19

i've done it few times executing

dd if=/dev/zero of=/dev/sda

no additional preparations. it worked. system was running fine for days after dd finished [responding to pings, forwarding packets].

share|improve this answer
A single pass with /dev/zero wouldn't be very secure depending on how secure the OP needs it. – Aaron Copley Jul 17 '12 at 19:24
Just tried this, and the result was a kernel panic. I have about ten more machines I can try this on though. What should I try next? – cat pants Jul 17 '12 at 19:25
Do you have specific partitions with confidential data? You can try sandblasting those first before doing anything that may take down the box. – cjc Jul 17 '12 at 19:36
I was under the impression that needing more than one pass is a common misconception. I believe that there is a challenge to recover data after a single pass with /dev/zero, and so far no one has been able to do it. – cat pants Jul 17 '12 at 21:38
@catpants: Lock the necessary files into memory with vmtouch then run whatever you need. – womble Jul 17 '12 at 22:55

Suggestion: use wipe rather than dd - it supports multi-pass secure wiping.

Another suggestion: stop as many services and delete as many packages as possible. Delete every piece of data that you don't need, and all of your old log files and data. Fill as much as possible of the resultant free space with a single file, then run wipe on that file. Don't delete that file. That will take care of wiping most of the disk before you make the system unusable.

The chroot ramdisk idea would then be necessary to get you past any dramas with getting back into the box, but you'll probably want to quiesce the system as much as possible before doing the final wipe, because logging and other daemons that write to disk could mean that real data is written to free data blocks while the wipe is happening, before the filesystem structure is fully corrupted.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.