Early actions for “child” virtual machines: Accounts/Names

Log in
login
Verify superuser privileges

Once you're logged in, if you are logged in as a standard user (which is the usual approach), then escalate privileges.

sudo ${SHELL}

or, maybe something even simpler:

sudo ls -l

If that doesn't work as intended, you may wish to check what details the sudo command will reveal (upon request).

sudo -ll

There is no need to remain escalated. Once escalated, if the command that was run was a shell, then go ahead and de-escalate.

exit

However, if there are problems with getting administrator-level (“superuser”) privileges, then knowing about those problems (and taking care of them) is probably something better to do sooner, rather than later.

Initial custom actions on new system

Perhaps there are some things that you want to do on every single system.

Optional: Update the file integrity checking database
Rationale: why now?

Some files, such as the SSH identity keys, may have been automatically created when the system started. (Since older versions of those files were deleted during the process of creating the “parent” image, the files were missing when the “child” machine was started. Some systems may detect such situations, and re-create the files.)

If that did happen, it may be nice to get the “file integrity checking” database updated. That way, automatically performed actions, which have already been done, may be seperated from future actions (which may be things that were done manually).

Files that may commonly be updated, at this point of the process, may include:

  • /etc/ssh/ssh_host_*key*
  • /etc/iked/local.pub
  • /etc/iked/private/local.key
  • /etc/isakmpd/local.pub
  • /etc/isakmpd/private/local.key

(Or, maybe some of these came from a cron job?)

  • /var/backups/etc_ssh_ssh_host_*key*.current
  • /var/backups/etc_ssh_ssh_host_*key*.current.sha256

If you take the time to do that now, it can make later reports smaller.

Newer method
aidedbup start-of-kid-KidName

Then, optionally:

echo ${PAGER}
aiderpvw | ${PAGER}
Older approach
Update system name

Once you have managed to login successfully, update the system name.

Rationale

Why is the system name so important that it ought to be done right away?

For people who access multiple systems (which is likely for a network administrator that has access to multiple servers, particularly if they are on the same network), this can help make sure that changes are done to the right system. (If changes are done to the wrong system, that typically means there are two problems: the right system is unchanged, and the wrong system is changed. Even if both of these problems would individually be relatively easy to reverse, sometimes a person can easily overlook at least one of those problems, even after discovering the other one. The best way to prevent having an unresolved problem is to not make the problem in the first place.)

To do this, you'll need to know the full desired host name, including the system name and the network name.

  • The name of the system ought to correspond to the VMGenNam environment variable on the parent host. Further information about naming a machine was discussed in the directions about how to Determine the name of the machine.
  • The name of the network may correspond to the VMGenNam environment variable on the parent host. Further information about naming a network was discussed in the directions about how to Name the net/proj.

Update the system host name.

If you don't remember the system host name, and if you are using VNC, then looking at the VNC window's title bar may show the host name that the “virtual machine” software is aware of. Another way, which may be more likely to work (but may be slower to check) is to see some details from the command line that started the virtual machine.

Changing the system host name in OpenBSD
ls -l /etc/myname
sudo cpytobak /etc/myname
hostname
cat /etc/myname

Before proceeding with this next part, be careful to make sure this is being done on the right system. (If the system was created as a “child&rduqo; image, then the proper name of the system would likely be the same name as the parent image that was used to create the child.)

sudo rm /etc/myname ; echo newsysname.mydomain.zz| sudo -n tee -a /etc/myname
cat /etc/myname
sudo hostname $( cat /etc/myname )

That last command might trigger a visible change in the prompt. (Tehnically, whether that is true, or not, would depend on what shell is being used. In all likelihood, it would also depend on the value of an environment variable. If the host name is part of a prompt, check whether the prompt got updated. If it didn't, and if the prompt is still showing an old name, try running hostname.)

Other/Misc Related Reading

Here are some additional resources. They are not considered to be part of this guide (and may be some older resources). Additional reading can be done from: new system security, and/or setting a host name.

Hopefully now, any command prompts (including any new ones that get opened, and any existing ones) will show the system name. Also, if the system has a graphical user interface, the desktop background might also include the system name.

Update DHCP client info
cpytobak /etc/dhcpd.conf
echo ${VISUAL}
sudoedit /etc/dhcpd.conf

Update the send hostname "sysname" line so it has this system's short name (as shown by hostname -s) in between the quotation marks.

Handle user accounts

Presumably, an account was used to log in.

The preferable course of action is to not rely on such an account for anything other than starting to get access to a new system.

Rationale

The parent image may have an account that is designed to be used for the limited purpose of starting up a new system. This design does have some advantages. This way, if any problems occur with accounts that are used more regularly, those accounts can be replaced, and hopefully there is relatively little trouble that happens with the account that is used to originally handle a system. Also, if there is ever any sort of trouble that requires an update to the account that is originally used to handle a system, fixing that could be a relatively challenging undertaking. Hopefully, though, fixing that won't also require additional changes made to other accounts that are used for other purposes, because that would increase the work of adjusting the original account. (In addition to fixing the original account, there may be need to adjust other things that the account is being used for.)

This could even be implemented by having an account use a known “one-time password”. The same “one-time password” would be readily accepted by each new system, so the password isn't truely “one-time”. (The password would be “one-time” per machine, but if it gets re-used, then it ends up being used more than “one-time” total.) Still, it would only be usable for a single time on each system. If this is done, then getting a new account set up soon is an essential priority, because failure to take care of this could require re-creating a child disk image, or taking some other steps to work around a lost password.

The downside to this approach is simply that there is a requirement, which is that another account needs to be altered (possibly by being created) soon.

  • You may wish to check for an existing user.
    • If the system has an existing user that fits the description, then there may be no need to make another user.
    • This can be checked with:
      grep -i ^wheel: /etc/group
      ls -l /home/
      grep -i ^_sshok: /etc/group
Backing up the user database

Normally, the general advice is to back up a file before adjusting it. However, since machine has had so few changes since it's been customized, there is no real need to back up the user database. Also, backing up the user database can be a bit complex (to perform the action in a way that works with many operating systems), so this guide indicates that such a backup is typically not needed at this point.

  • Understand that this step might be more sensible to perform at a later time. (Unless additional instructions indicate otherwise, it may be most sensible to delay until after remote access is functional.)

However, if you wish to back up the database anyway, see: backing up user database.

export FILETOBK=$( sudo ${SHELL} -c " ls -1aF /etc/*group /etc/*passwd* /etc/*pwd.db* /etc/*shadow* 2>&1 " | grep -v "No such file or directory" | xargs )

Now that you've got the filenames in a variable, the rest of this process is to perform the actual backup. That part of the process may now be easier than the first time these instructions recommended backing up this data (because the cpytobak program hadn't been installed earlier).

echo ${FILETOBK}
sudo cpytobak ${FILETOBK}

The recommended method for handling user accounts is to have a “username”/account that exists on this machine, but which does not exist on the parent disk image. That way, if there is an issue inherited from the disk image, child images won't be affected by it.

If account is needed

If the desired user account does not exist yet, make it. Adding User Account(s)

sudo adduser
  • Check the project documentation for details about what name should be used.
  • Plan to place the account into the groups named “wheel” and “_sshok” (in addition to whatever group a new user goes into by default).
  • Make sure the username is documented in the network documentation (that you create)
Otherwise...

If the account exists, and you simply need to change the password, then run the following command, customizing it to reflect the username that will regularly be used to manage the system.

sudo passwd username
Rationale for using root

(Note: In theory, superuser privileges aren't needed. So you could use: “sudo -u username passwd username”. However, in practice, the big difference is that running passwd as the superuser doesn't require typing in the old password. So leaving off the “ -u username” makes the process go faster.)

...

Log in (escalated)
login: 

Log in with the non-root user account that can escalate to use superuser privileges. Preferably, if SSH needs to work (eventually anyway), and if networking is currently functional already, then use SSH to log in. That will help to verify things (like the SSH configuration allowing the specified user account to use SSH). The need to log in as a new user is great for testing multiple things:

  • Verifying the SSH keys
  • Confirming that SSH server is running
  • Confirming that networking is functional enough for that SSH server to be usable
  • Confirming that the user has permissions to use SSH
  • Confirming that the user can escalate

If SSH is not feasible, any other “remote access” protocol could be used, or the system's “local video display” could be used. (e.g., using Qemu's built-in VNC server).

If you are going to use some sort of “remote access” protocol, such as SSH, by communicating with software that is running on the new “virtual machine”, then figure out the virtual machine's IP address. For instance, if the only available NIC is named em0 then:

ifconfig em0
Using SSH
ssh -p 22 -l username 198.51.100.2

or, if a key file is being used:

ssh -p 22 -l username -i privkey 198.51.100.2
Other methods to log in

If networking isn't functional (or using networking is just not feasible/desirable for some reason), you can use the system's local display. You can switch to another terminal, typically by pressing Alt-F2 or Ctrl-Alt-F2. Another option may be to use a terminal multiplexer (described by: terminal multiplexer section), and then forcing a login using “sudo login”. (Enough login failures, however, may cause that login prompt to simply exit back out.)

Disable temporary account

If a long term account was created, then disabling the original account can help to prevent someone from using that account to gain access to the system. Disabling the original account should be done using the new account. That practice helps by forcing the user to log in with the new account, and escalate permissions with the new account.

Once logged in... disable the user account (see: Enabling/Disabling User Accounts).

Example

e.g.:

sudo -E vipw

(Then place an asterisk (“*”) at the beginning of the password field, as described by Enabling/Disabling User Accounts: section on “Disabling Unix system user accounts by modifying login password/credential information”).

Also check out the user's ~username/.ssh/authorized_keys file, if it exists.

  • Customize the second line, to correctly refer to the “stock” username that was used to create the currently-logged-in user.
echo ${OLDUSRHM}
export OLDUSRHM=~olduser
  • You may be able to set the variable some other way. The following is an example that has been known to work on a system with three usernames. (This may be more complicated than doing it manually, and is not necessarily recommended. This is meant for as a demonstration than a recommendation.)
    echo $( ls -1tr /home/ | head -2 | tail -1 )

  • echo Sample: OLDUSRHM=$( ${SHELL} -c " echo ~$( ls -1tr /home/ | head -2 | tail -1 ) " )

    (If one of the echo commands showed the desired directory, you can do something along the lines of switching the echo command to an export command.)

    Anyway, somehow get OLDUSRHM to point to the home directory of the user that is getting disabled.

echo ${OLDUSRHM}
sudo cat ${OLDUSRHM}/.ssh/
sudo ls -l ${OLDUSRHM}/.ssh/

If such a file exists, and is non-zero bytes, containing data that should be disabled, then go ahead and disable it:

sudo mv -i ${OLDUSRHM}/.ssh/authorized_keys ${OLDUSRHM}/.ssh/disabled-authorized_keys
sudo ls -l ${OLDUSRHM}/.ssh/
unset OLDUSRHM
Re-check
At this point, I generally like to close the SSH session and re-open it, just to confirm that I didn't do the silly action of disabling the wrong account.
Log out of other username

So now you've logged in as the new user account. If you are still logged into the old account, on another window, log out. (That way, nobody can do something that re-enables the ability to log into that account, like trying to install a private SSH key to the account.)

Passwordless login

While we're discussing the topic of controlling which users can log in, let's take a look at how they can log in. This may be a reasonable time to start enabling “passwordless login” ability for the newly created account.

Note that this step cannot be tested (decently well and simply) if networking is not functional yet. Also, if networking is not functional, then that can add some difficulty to the process of sharing keys. So, if networking is not functional yet, then skip this step for now. However, if networking is functional, then this is likely a reasonable step to perform at this time.

  • Get networking working. (This is good to do anyway, even if passwordless logins are not being used.)
  • For now, this guide does not fully cover this process, so this is considered to be an optional part of the guide. Skipping it is currently recommended. (If you really want to pursue this, there are instructions at deploying SSH keys.)

Use available tools (such as a text editor, “copy and paste” ability, file transferring, etc.) to get an SSH public key into the new user's ~/.ssh/authorized_keys file. Just be careful to not place the actual credentials (the public key's data) on the command line. (Commentary about why... has been written... somewhere... else)

For the following example commands, the USRHOMDR needs to be customized. (It is used in multiple locations.)

  • If you are logged in as the user that you wish to enable remote access for, you may be able (perhaps easily?) to set the value of that variable to “ $(id -un ) ” or ${USER} (although the variable needs to be set to that user's home directory, not the user's name).
  • Otherwise, just customize its setting manually:

    export USRHOMDR=~username

Check that the filesystem isn't specifying writable access for any group, or other user.

ls -ld ${USRHOMDR}/ ${USRHOMDR}/.ssh/ ${USRHOMDR}/.ssh/authorized_keys

The file must also be owned by the user. If necessary, make changes. (Some of these example commands may be untested at this time...) (Be careful to customize the username for the chown command.)

sudo chown username ${USRHOMDR}/.ssh/authorized_keys
sudo chmod og-w ${USRHOMDR}/ ${USRHOMDR}/.ssh/ ${USRHOMDR}/.ssh/authorized_keys ${USRHOMDR}/.ssh/authorized_keys
ls -ld ${USRHOMDR}/ ${USRHOMDR}/.ssh/ ${USRHOMDR}/.ssh/authorized_keys
unset USRHOMDR

Related content: Permissions required for the authorized_keys* file