Removing Identify Files from Base/Parent Image

Removing files that re-generate uniquely

Rationale: Why this is done

Some files should be re-created uniquely on each child image. Hopefully randomization will notice updated times and/or other unique details, and cause different files to be created with each new child image. As a result, each child image will have its own unique files that are used to identify the system. This means that each child image will (hopefully) end up having its own unique identity. That is a good thing, which is desirable.

Some people may wonder why the ISAKMPd and IKEd files get removed. That causes every child to re-create those files, which may seem like a waste for children that don't use ISAKMP and IKE. The SSH key files (or, at least, some of them) are rather important, but why waste time with these?

Well, it is a waste, but it is a matter of the principle of doing things correctly. An analogy would be if a young adult travelled to a college, and then found out that this person had a copy of mom's birth certificate. This person grabbed the wrong birth certificate before moving.

Now, this person might not really need to use the correct birth certificate, since a driver's license may be suitable on a day-to-day basis. Yeah, sure the issue could be corrected if it ever became important enough to deal with. And, the issue might not be important enough to need to correct. However, the situation is still incorrect.

As a matter of principle, it is nice if identify files are doing a correct job of identifying a computer, instead of impersonating another computer. So, we remove the offending files to remove an incorrect situation, and this will result in a correct situation (when the child re-creates the files).



Either the manual way, or the slick way

manual way
  • ISAKMPd files:
    sudo rm /etc/isakmpd/private/local.key
    sudo rm /etc/isakmpd/
  • IKEd files:
    sudo rm /etc/iked/private/local.key
    sudo rm /etc/iked/
Slick way
sudo rm /etc/{isakmpd,iked}/{private/local.key,}
Rationale: Why this is done the way it is

This may be easiest to do as root. This guide generally recommends performing tasks with sudo. However, some of these commands may be particularly prone to files being inaccessible to a standard user. As a result, when the standard user types a command, wildcards might expand differently than if the command is run as root.

Therefore, the recommendation is to run as root.

sudo ${SHELL}
Stop the DHCP client

Stop the DHCP client. Otherwise, a new DHCP lease may be created after deleting an old one. As long as network connectivity is still functional, creating the new lease will be undesirable. This approach might run some small risk of violating specification by using a DHCP-assigned address after the lease expires, although chances of that happening are rather low. (Also, the chance of that actually causing a problem, during the short time period that the DHCP client won't be running, is... even lower.)

Stopping the DHCP/IPv4 client in OpenBSD

Stopping the client may disrupt the SSH session. If you're doing this over SSH, start by opening up a terminal multiplexer.

  • The reason to use this is to make sure that all parts of a compound command run. With some systems (possibly not OpenBSD, or any recent version) there could be a risk of the following happening:
    1. First command runs, which intentionally breaks things
    2. Before system runs second command, some software (the operating system, or perhaps more specifically, a server) realizes the results of the first command
    3. An active network connection is broken
    4. A “command prompt”/terminal closes
    5. The next command in the compound command is never run, because the terminal closed before it got around to being able to fix things

This unfortunate behavior has been seen. (Granted, this may have been on dial-up connections, and possibly using some old (and currently obscure) operating system; perhaps VMS... Still, it has been seen.) Using a terminal multiplexer was effective in making sure that the program could fix things.

Possibly related/similar topic: Protecting terminal used by VM

Figure out what IP address(es) should be active after the DHCP client is stopped.


First, find the section related to the network interface that is being used, which is probably not lo0, nor enc0 nor pflog0. With Qemu emulating an Intel PRO/1000 10/100/Gigabit Ethernet device, em0 is a common value.

The following will stop the DHCP/IPv4 client, and set the IPv4 address manually.

ps -auxww | grep -i dhc | grep -v grep
sudo pkill -l dhclient ; sudo ifconfig em0 inet prefixlen 24
ps -auxww | grep -i dhc | grep -v grep
  • If you entered a terminal multiplexer (which was something that should have been done), go ahead and exit it.
    • At this time, it is NOT intended to use exit to de-escalate, nor to log out. The only point is leaving the terminal multiplexer.
Other operating systems

Here are some resources to help:

For instance, some systems use killall instead of “pkill -l”. If neither command exists, kill can also be used, by specifying the PID of each process that needs to stop.

Then, remove (with rm filespec) the following files. (You can use ls -lF on the files first, if you like.)

Some files to remove
  • DHCP client lease(s): /var/db/dhclient.leases.*
    • If DHCP has not been used, then the file might not exist. That's fine.

    • ls -l /var/db/dhclient.leases.*
      rm /var/db/dhclient.leases.*
      ls -l /var/db/dhclient.leases.*
  • System key files mentioned by system SSH keys. These include /etc/ssh/ssh_host_*key and /etc/ssh/ssh_host_* files.
    • (Just as a side note, the specified files match /etc/ssh/ssh_host_*_key* filespec, except for /etc/ssh/ssh_host_key* files which have only two underscores per filename. Those files are why a filespec with three underscores wasn't used.)

    • ls -l /etc/ssh/ssh_host_*ke{y,}
      rm /etc/ssh/ssh_host_*ke{y,}
      ls -l /etc/ssh/ssh_host_*ke{y,}

If the SSH keys were deleted, then relevant data from SSH clients may also be a good idea. In Unix, review ~/.ssh/known_hosts and find any line with the IP address of the system that had its keys removed. All such lines in that text file are useless, and should be removed. For other SSH software, see when there is no saved SSH key.

Perform the following steps when the old SSH keys are getting removed:

That concludes the list of files that are likely to use wildcards, so you can run:


to stop being logged in as root.

Editing user database
sudo -E vipw

Disable the logins for any accounts that don't need to be logged in. In general, there should just be ONE account that can be logged in. (It should NOT be named “root”.)

Also, the order of the lines is not really significant. It may be nice to place the active account on the last line (or the first line) of the file, to help it be found more easily. Child images will want to disable this account after making a new one, so the idea here is to save future time by having this account be easily findable.

Pick a password

Set the password to something appropriate for the parent image. For example, if a publicly-published password is acceptable for this parent image, “plzreset” may be useful. (With that example, anyone who has to type that password will have a reminder that they should customize the password.)

Removing more SSH keys/data

See the list of the “home directory” locations in the operating system's standard spot. (Use “ ls -l /home/ ”, or, if that doesn't find anything, try “ ls -l /users/ ”).

sudo ${SHELL} -c " ls -l /home/*/.ssh/. "

It is recommended that all such files named authorized_keys or known_hosts (not files named config) be reduced down to zero bytes. (Deleting the files may be more work, but then newly created files will generally need to have their permissions altered. Using a text editor to blank out the contents will generally make things a bit nicer in the future.)

  • Alternatively, it may be desirable to keep the information. For instance, if a host has been verified, then keeping that information in known_hosts might be useful. The recommendation to delete the information is based on the idea that the information may become stale. If a key gets replaced, having old information may be even more cumbersome than having missing information. So, this recommendation is based on the idea that people will be better served by just removing the information ahead of time. However, other decisions could be made by a network designer who expects key handling to be different. Like many details in this guide, customizations may be appropriate (although some customizations might not be recommended in formal training environments where a group of people are anticipated to be following many directions).
  • Alternatively, you could just comment out lines or partial lines that are desirable to keep; both authorized_keys or known_hosts recognize lines starting with # to be comments. However, deleting the keys may make the keys more challenging to recover (maybe even completely infeasible, if the information gets overwritten), so that is preferred.

Also do likewise for ~root/.ssh/authorized_keys and ~root/.ssh/known_hosts if they exist.

sudo ls -l ~root/.ssh/.
User s/key data

S/key data probably should not be re-used among different children, so all S/Key support for all users should probably be deleted. A small typo, like leaving off the word “skey” in the rm command, could be catastrophic. Even misspelling the word slightly as skel would likely have unintended consequences. So, be careful with this.

sudo ls /etc/skey/.
sudo rm /etc/skey/*
Randomization keys

It is not currently clear whether this is a good idea... so this is being inserted into the guide as a possible idea for further research. Chances are that even if it is a good idea on OpenBSD, maybe it isn't a good idea for other operating systems.

Consider removing /var/db/host.random

It seems these files are saved at every shutdown. However, it would probably be best that different machines don't start with the same entropy, so removing the files from the parents might lead to children re-creating fresh files, which might be better.

A resource, that might possibly be rather useful to consider looking at: OpenBSD source code for /etc/rc file's “random_seed()” function.

NTP drift

It is not currently clear whether this is a good idea... so this is being inserted into the guide as a possible idea for further research. Chances are that even if it is a good idea on OpenBSD, maybe it isn't a good idea for other operating systems.

Consider removing /var/db/ntpd.drift

If multiple children are created from the same parent, having the same drift file to start with might actually be sensible. However, if the parent image is going to be used over a longer period of time, it may make sense to just start with a blank slate, instead of using information which (eventually) may be quite old.


You may wish to remove the /etc/adduser.conf file. If the file is removed, additional questions get asked when creating a user. This is probably unbeneficial, as it will result in taking a bit of additional time. However, it might feel kind of neat to do, just because it makes the system “feel” a bit more like a freshly-installed, uncustomized system.

Might be OpenBSD-specific.

Some related material for additional/further reading

If you'd like to see another page discussing identity files, Removing files that re-generate uniquely may also cover this topic. (It mentions anti-virus definitions. However, that isn't currently covered as part of this guide.)