|
Well, there are a two easy solutions here:
1) You could get rid of
some of the bulkier services by switching to runlevel 2. Although
runlevel 2 is meant to be multi-user mode without networking, for me
the networking still worked fine, sshd was still there, httpd, ftpd and
a whole bunch of other stuff gets shut down and init takes care of
everything for you. (On Redhat inspired systems you can use "chkconfig
--list service" to see which run levels it runs on).
2) Its very easy to
initiate remote commands via ssh. If you have the keys set up properly
(plenty of info on this on net) you won't have to supply a password at
all. You can either execute the command via ssh directly as root or
add a line line to /etc/sudoers file, like "username ALL= NOPASSWD:
/sbin/init 2".
3) ssh [EMAIL PROTECTED] "init 2"
Gadi
Shlomi Fish wrote: Hi all! The iglu.org.il server had to be rebooted several times in the past months, because it has become unresponsive. It has some potential problems like a lack of enough memory, etc. (we are planning a memory upgrade). Nevertheless, this time (and as I recall others) it still answered pings and could initiate HTTP connections.What I would like to have there is a lightweight network service that upon receiving a remote signal will initiate a shutdown of all services except sshd. I'll worry about what exactly to shutdown and how, but would like to consult the collective wisdom of Linux-IL regarding how to securely transmit the signal. The scheme I've been thinking is this: 1. My home machine (let's call it Redwolf) initiates the connection. 2. The service (let's call it Eskimo) sends Redwolf a random string of bits. 3. Redwolf receives this string and encrypts it using a symmetrical (= private key) key algorithm, and using a key that only him and Eskimo knows. (Assume that this key can be decided upon in advance). 4. Redwolf sends the encrypted string back to Eskimo. 5. Eskimo encrypts the string he sent Redwolf himself, compares it to the string Redwolf sent and if they are identical initiates the shutdown process. Is this scheme cryptologically secure? (Assuming there isn't a weakness in the encryption algorithm). Was it proven to be so? If it does have a weakness what is a better (and hopefully proven) scheme? Thanks in advance and I'm sorry that I didn't use Alice and Bob here. Shlomi Fish --------------------------------------------------------------------- Shlomi Fish [EMAIL PROTECTED] Homepage: http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%. ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- Gadi Cohen aka Kinslayer <[EMAIL PROTECTED]> www.wastelands.net Freelance admin/coding/design HABONIM DROR linux/fantasy enthusiast KeyID 0x93F26EF5: 256A 1FC7 AA2B 6A8F 1D9B 6A5A 4403 F34B 93F2 6EF5 |
- Re: Crypto: Securely Invoking an event remotely Gadi Cohen
- Re: Crypto: Securely Invoking an event remotely Orr Dunkelman
- RE: Crypto: Securely Invoking an event remotely Rony Shapiro
