Is there a way to easily shutdown a remote linux server with a shell script?

bdb4269 · 01-26-2007, 01:49 PM

I have 3 linux servers hooked to my UPS. I can only hook the UPS to one of them. The UPS software will allow me to run a shell script on that one server before it shuts down. And I want that shell script to shut down the other 2 servers. Is this possible?

Tinkster · 01-26-2007, 02:07 PM

sure.

Enable passwordless ssh between service accounts on all machines,
give the service account the ability to shut the machine down.

And then:
ssh account@machine -C "halt"
from the script.

Cheers,
Tink

bdb4269 · 01-26-2007, 02:19 PM

I am not sure how to enable passwordless ssh between service accounts on all machines.

Tinkster · 01-26-2007, 02:25 PM

Use the search, Luke!

There's a tutorial on this on LQ - can't be bothered to reproduce it here

Cheers,
Tink

MOS JEFF-INITELY · 01-26-2007, 02:34 PM

you can also use rsh which runs remote commands on remote servers.. much easier than ssh for setup.. but much much less secure

bdb4269 · 01-26-2007, 03:21 PM

Thanks much! Im all set.

RESOLUTION (ssh method):
Here's what I did...

First I ssh'd from each machine to each other one. (The first time u ssh to new machine it asked you to accept the machines "fingerprint" and saves it -- this is just so they know who eachother are.

Then on the machine I wanted to be able to shutdown FROM I did

Code:

cd /root/.ssh/
ssh-keygen -t rsa

and accepted the default location. (/root/.ssh/id_rsa)
I left the passphrase blank, so it would not be required.

Then basically you just need to copy that "id_rsa" file onto the DESTINATION machine, in the same directory, but named as "authorized_keys". Which can easily be done like this:

Code:

scp id_rsa.pub xxx.xxx.xxx.xxx:/root/.ssh/authorized_keys

Where xxx.xxx.xxx.xxx is the IP address or host name of remote machine.

NOTE: You may want to check if a file by that name already exists, on the remote machine, because the above command will overwrite it without warning. -- If you aleady have a file by that name on the remote machine, I would suggest using comand above, but change the file name. Then on the remote machine, append the file you just copied to the existing one. This could easily be done like this: (there may be an even simpler way - but this is what I know)
Code:
mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys.backup
cat /root/.ssh/authorized_keys.backup /root/.ssh/yourfilename > /root/.ssh/authorized_keys

Then make sure the /root/.ssh/authorized_keys file has 600 permissions.

Code:

chmod 600 /root/.ssh/authorized_ keys

Then try to ssh to the remote machine.

Code:

ssh xxx.xxx.xxx.xxx

And if it works like it did for me -- it will let you right in, with no username or password. If this works correctly, you should be able to remotly run commands through ssh within scripts.

Tinkster · 01-26-2007, 03:44 PM

That's basically it, even though root may not have been the
wisest choice. If one box gets hacked the attacker gets full
access to all of them w/o any hassles. I suggested "some
service account" and still think that this is what you should
be using; e.g. create a user "downer" w/o a login-shell, have
that account set-up in the way described above, and give him
the right to shut-down the box, e.g. via sudo which would
slightly complicate the invocation.

Cheers,
Tink

bdb4269 · 01-26-2007, 04:08 PM

Thanks for the warning. A quick question about that...

These servers are pretty much entirely local. (security is not a concern at all for me locally) -- The only public access to any of the servers is one of them is set up as an FTP server (ProFTP).

Here are the security measure I have in place for the FTP server.

a secure connection using AUTH TLS is required before the user command is accepted
there is no anonymous access
connections are only accepted on port 49999 (21 is stealth at firewall)
the server does not identify that it is ProFTP (i was told this was good, in case of bugs, people wont know what your running and therefore what they can exploit)
all users are locked in their home directory (and there are only a handful)

Given, this, do you think I need to worry about the possibility of an external intruder somehow gaining shell access?