System Stopping User

May wish to create a new SSH key. This way, the ability to shutdown/reboot might be given (to a person... or a program, such as a script) without providing full access to make tons of changes. Using a separate key is not a whole lot more work, but it does offer substantial more flexibility later.

Prepare a “user” account
Choosing a username

A key first step is to decide what user will be shutting down. It may be nice to create a new user that is dedicated to shutting down the machine. This may help create log files that are a bit more clear (because seeing the username will be an indication of what the user is authorized to do), and might help prevent accidental shutdowns (caused by accidentally selecting the wrong key, since shutting down could also require specifying the username). This can also provide some flexibility, because an account (being used by an user who is interactively logging in, or perhaps used by an automated process) can shut down the machine without also unnecessarily having permissions to do things like changing sensitive configuration files.

e.g., The guide at at sys stop: using a special, dedicated user account to reboot discusses/mentions possible usernames.

Note: This user account does not necessarily need to be unique to this machine. If there is another machine that is permitted to be shutdown by the same people who can shut down this machine, there is no compelling reason why a different account name needs to be used.

Once the username has been decided upon:

  • Make sure the username is documented
    • (Document the username that will be used for the purpose of shutting down the system, unless the username is part of some sort of standard that is already documented.)
  • create the user.

The user will also need to be able to have elevated permissions, but the guide will address that requirement in a moment. There is no need to have the user be able to elevate permissions as soon as the user is created. (Do not place the user into the “wheel” group.)

Access shutdown key

Verify that you have access to an SSH key that is used for the purpose of shutting down a system. If you don't have a key that is dedicated to this purpose, you may with to make one. (See: adding an SSH key.)

On the machine that is going to be shut down...

export USRTOCFG=_endnow

(Customize that username as needed.)

At this point, the following is assumed:

export HOMTOCFG=$(eval echo \~${USRTOCFG})

(If you are logged in as the user that will be getting adjusted, then you could just use ~ as the value for ${HOMTOCFG}.)

sudo mkdir ${HOMTOCFG}/.ssh/
echo ${VISUAL}
sudoedit ${HOMTOCFG}/.ssh/authorized_keys

... place the following on a new line of the ~/.ssh/authorized_keys file:

command="sudo /sbin/shutdown -hp now Shutdown initiated with SSH by \\"$USER\\" CONN rem/lcl=\\"$SSH_CONNECTION\\" CLI rem/lcl=\\"$SSH_CLIENT\\" CMD=\\"$SSH_ORIGINAL_COMMAND\\"",no-agent-forwarding,no-port-forwarding,no-X11-forwarding 

Notice that there is a space at the end of that text. That should be there.

Then, after the space at the end of that text, place the public key.

So, the line on the text file may fit this sort of format:

command="sudo...",no-agent-forwarding,...,no-X11-forwarding ssh-dss AAAAB3NzaC1kc3MAAACBA...= optionalComment

The information from the public key should contain a comment that identifies the key, as noted by: Recommended further modification: SSH public key file's comment If that hasn't been done already, please proceed to take care of that.

Also, set permissions for the file. There is likely no need to do this if the file has already had permissions adjusted, but it doesn't hurt to do so again. (See: Handling OpenSSH permissions for writing.)

sudo ${SHELL} -c "ls -l ${HOMTOCFG}/ ${HOMTOCFG}/.ssh/ ${HOMTOCFG}/.ssh/authorized_keys* "
sudo ${SHELL} -c "chmod go-w ${HOMTOCFG}/ ${HOMTOCFG}/.ssh/ ${HOMTOCFG}/.ssh/authorized_keys* "
sudo ${SHELL} -c "ls -l ${HOMTOCFG}/ ${HOMTOCFG}/.ssh/ ${HOMTOCFG}/.ssh/authorized_keys* "

Then, you may: “ unset USRTOCFG HOMTOCFG ”.

Further info/discussion about this proceess has been at: Using an (OpenSSH) SSH key to use (only certain) commands, Allow the user to log in using a specific key

Allow this user to shutdown the system without requiring a password for sudo. This is not needed if the user is already able to use sudo to run all commands without a password. However, if it is needed, you can perform the following steps. Back up, and start editing, the /etc/sudoers file:

cpytobak /etc/sudoers
echo ${VISUAL}
sudo -i visudo

If the user's name is “_endsys, then make a line that says:

_endsys  ALL=(ALL) NOPASSWD:/sbin/shutdown -h*, SETENV: ALL

(Otherwise, if the username is different, simply do something similar after customizing the username as appropriate.)

Go ahead and test the results, by “remotely” shutting down the virtual machine (by using the private SSH key).

ssh -i privateKey -l userName -p 22 remotesys

If you get a prompt asking for a password, try to determine whether the password is coming from the SSH authentication, or from the sudo command. Ideally, you should get neither prompt, but identifying the prompt can help to determine where to troubleshoot.

Making the physical machine's script

After confirming that worked okay...

Starting the virtual machine

Go ahead and start the “virtual machine” again. There is no need to wait for it to finish booting up, since the next instructions are related to tasks to do on the (“physical”) machine that runs the “virtual machine” software.

verify virtualization variable values


On the (“physical”) machine that runs the “virtual machine” software:

echo VMDirBas=${VMDirBas} VMGenNam=${VMGenNam} VMLILNAM=${VMLILNAM}
sudo mkdir ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstop/
echo \#!/bin/sh| sudo -n tee -a ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstop/stop_${VMLILNAM}

For the next command, do not type in the entire command line. If “copy and paste” features are not available, at least try to use command line history/recall features. Press the up arrow three times so that the ssh command line shows up. Then press Ctrl-A to get to the beginning of the line, and insert the word “echo ” (and the space after the word “echo”). Then press Ctrl-E to get to the end of the line. An alternative to those Ctrl key combinations is to use the horizontal arrow keys. The command is:

echo ssh -i privateKey -l userName -p 22 remotesys| sudo -n tee -a ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstop/stop_${VMLILNAM}

(This script file can be notably more complicated, like trying to first detect whether the virtual machine is running before proceeding to start the ssh command. However, this is the simple version of the script that is rather fast to create.)

That line probably needs some customizing... or you may want to just run that line as it shows, and then edit the script file.

echo ${VISUAL}
sudoedit ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstop/stop_${VMLILNAM}

There are some permissions that may be needed.

sudo chmod ug+x,o-x ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstop/stop_${VMLILNAM}

Finally, shutting down the virtual machine can be as easy as running a command on the (“physical”) computer that runs the “virtual machine” software. Make sure that the “virtual machine” is fully booted up (if needed, check out using Qemu's built-in VNC server), and then try the shutdown script:


The quickest acknowledgement that the shutdown process is starting will probably be the SSH client receiving (and displaying) this message:

Shutdown NOW!
shutdown: [pid #####]

(Furthermore, the OpenSSH client may provide this message.)

Connection to demo.example.zz closed.

At some point, shutting down or rebooting a system will cause some other things to happen. These other things will acknowledge the system shutdown:

  • Any other SSH servers will disconnect
  • The kernel will display a message on the (virtual) machine's standard video display
  • If the system is getting powered off, then the VNC server will stop, which will cause the VNC clients to close

However, it might take some time for the system to shut down some key software, unmount the filesystems, and perform some or all of those actions. Waiting 45 seconds to a minute might be somewhat common. (Depending on what softare is being used, even longer waits may be needed. Database servers, Microsoft Exchange mailbox servers, and systems that try to perform software updates have been known to take much longer, including times that might exceed ten minutes. The precise details can vary based on factors like hardware, although software is often an extremely significant factor in how long the system takes to shut down.)

State of vm electrical power

Based on what comes next in the guide, you might want to just leave the virtual machine off a bit.

However, if there is a desire to start it up again, here are a few quick pointers about how to do so.


using Qemu's built-in VNC server