A better way...
Yes, there is a better way to do this. Make it so that shutting down does not require superuser privileges.
This requires a bit of setup in advance. Then it minimizes who can perform the privileged action, and just what can be accomplished by a person who uses that method. (In other words, potential abuse of the power is constrained by some other limits that exist.)
I am presuming installation of some common software, including
sudo (seems like a safe presumption, considering the question), and OpenSSH (or, probably more likely, "OpenSSH Portable").
Create a user account
Since you seem to have
sudo access, I presume you probably have the ability to create a user.
You may want to call the user _sysstop, or _sysoff, etc. Although "shutdown" is eight characters or less, that is also the name of a command to run, so using a different name may be nice. I also like the standard of starting entirely automated accounts, like this one, with an underscore, just so that visually this account ends up looking different than a standard user account.
Let user shut down without password
Modify /etc/sudoers, and insert this:
_sysstop ALL=(ALL) NOPASSWD:/sbin/shutdown -h*, SETENV: ALL
Naturally, you may want to customize that first part, which is the name of the user account you created.
A lot of people seem to oppose using NOPASSWD, probably because they don't like the idea of giving full access to do anything on the system. However, this is giving rather restricted access. The only thing that this person is going to be able to do is to run a command that starts with "/sbin/shutdown -h", which will halt the system. If some unauthorized person manages to take advantage of that line without a password, they may be able to shut down the system, but that doesn't mean that such an attacker would be unrestricted in ability to do lots of other types of damage (like setting up additional user accounts, etc.) So, this usage of NOPASSWD is rather safe in contrast to what most people try to discourage.
The "/sbin/shutdown -h" is what I wanted to use. Depending on your operating system, and what you desire, you might want to use a different command, such as "halt" or "reboot", and may want different parameters. Since you're already practiced in shutting down the system the way you want it, then presumably you know already know how you want to be doing this.
Create an SSH key
ssh-keygen -t rsa -vvv -f mykey -N "" -C "mykey" | tee mykey.fng
Some people won't like
-N "". Well, that is an entirely different discussion that I choose not to go into further here, beyond the rest of this statement: customize according to whatever security practices make you more comfortable.
There may be other changes, to the above example, that some people would recommend. Again, that may be excellent, but is a separate topic from the core of this answer. Customize the above however appropriate.
Notice the "mykey" shows up three times in the above example. You are absolutely welcome to customize the first example, and then the other occurrences are intended to match whatever the first occurrence says.
You don't need the mykey.fng file. I just got into the habit of preserving it so that I could have a record of the VisualHostKey (a.k.a. "random-art"), before I learned that such keys can be seen again later, e.g. "ssh-keygen -lvf /etc/ssh/ssh_host_ecdsa_key"
Restrict what can be done with the key
~$( echo username-just-created )/.ssh/authorized_keys* file. (e.g.,
~_sysstop/.ssh/authorized_keys although some systems might use
~_sysstop/.ssh/authorized_keys2, although you probably want to be using authorized_keys)
Implement the ssh key, by inserting a line that looks approximately like this in the file:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAA... Optional-comment-after-the-space
For the "Optional-comment-after-the-space", I like to include the filename of the private key. If I ever want to add an additional key (which I might not for this particular type of user, but out of habit, some users may want additional keys), then the authorized_keys file may have lots of lines that are identifiable by the key's text. If I have multiple keys, and then months later want to remove one, I might have a hard time remembering which public key is related to which key file, and so I wouldn't know which public key to remove. By utilizing the optional comment, I can keep that of this better in the future.
Note: if you automatically add the key (perhaps with ssh-add), maybe you have a default comment that contains a username. Such comments are often pretty useless. Customize in a way that may be useful down the road.
~/.ssh/authorized_keys has the needed permissions to make OpenSSH happy.
Test the single steps
Can you test this (by shutting down the system)? If so, doing that can test some components separately, which may allow you to have a more-narrowed-down problem if something is broken.
Test that the key is set up right.
On the client, use
ssh -i ~/keys/privkey-file _sysstop@localhost
If you use PuTTY, PuTTY also supports
-i filename (and
-ssh), or use the GUI to specify the filename in Connection\SSH\auth (in the left frame of options), which you can only do on the "New Session" screen. (Specifically, I say "only" because the "auth" screen does not appear when trying to use PuTTY's "system menu" and using "Change session" on an existing session)
At this stage of the process, this should give you a shell. If not, you may need to adjust the implementation of using the SSH keys.
Once you are logged in, test that the sudo works (without a password) to shut down the system
Restrict the key
~/.ssh/authorized_keys* file? Great. Now, modify it.
Find the line that starts with
Insert some text before it, so that the line looks more like this:
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 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAA... Optional-comment-after-the-space
Guard that private SSH key file. With it, anybody could shut down the system. However, that is really all they can do.
Now, shutting down the system simply requires running the unprivileged command "ssh", and access to that file. As long as you control access to that file, you're keeping things as secure as they need to be. However, even if the file does get compromised, the amount of damage that can be done is pretty limited.
Now you don't even need to type sudo when you want to shut down the system. You do need to make sure that nobody unauthorized gets that key (or else they could shut down the system). Presumably anybody who could use "sudo" to steal that file could also just use "sudo" to shut down the system, so in many cases, leaving the file in a private area of the computer is probably a relatively safe and reasonable risk.