Hi, Bettina, thanks for looking at this.

When a newbie like me looks at these things, there is a lot of mystery in the air, whereas there is no mystery for people who have a firm, deep grip of the topic.

In any case, if I disable the root account again on the host, then the only way I know of to run the ssh ... shutdown command is with sudo, and I don't know how to create a script for automated shutdown that uses sudo and doesn't require a manually-entered password.

Regarding the use of public key authentication, I believe I'm already using that, but maybe I didn't set it up quite right if I'm not getting the right results. As faras I know, the passwordless root account was a separate item in the recipe. Following is what I think I have doneto get to the current state:

(This is probably not a complete set of steps. And sudo is required for some commands below beyond the ones already noted.):

# Enable the root user account on the LTSP host and make it passwordless:
sudo passwd root             (and entry of a new password is required)
sudo passwd -d root

# Generate ssh keys for client management
ssh-keygen -q -N "" -f /root/.ssh/id_rsa
chmod 600 /root/.ssh/id_rsa.pub
mkdir -m 700 /opt/ltsp/i386/root/.ssh/
cp /root/.ssh/id_rsa.pub /opt/ltsp/i386/root/.ssh/authorized_keys

# Suppress meaningless host key messages in ssh client
# Note that this does not reduce security when connecting to thin clients, but could compromise # security when connecting to other ssh servers, as it defeats host key checking
echo "StrictHostKeyChecking no" >> /etc/ssh/ssh_config
echo "UserKnownHosts=/dev/null" >> /etc/ssh/ssh_config

# Install the SSH server in the chroot environment
sudo chroot /opt/ltsp/i386
apt-get install openssh-server

#  Also in the chroot, enable the root user account and make it passwordless
sudo passwd root            (and entry of a new password is required)
sudo passwd -d root

# Update the LTSP image:
export LTSP_HANDLE_DAEMONS=false
sudo chroot /opt/ltsp/i386
mount -t proc proc /proc
exit
sudo ltsp-update-kernels
sudo umount /opt/ltsp/i386/proc
sudo ltsp-update-image

# Shut down one client from a host console (to be expanded with a for ... do loop)
ssh -l root <LTSP client IP> shutdown -h now

-----------------------

Overall, I'm looking for the best way to automatically shut down a small LTSP network running on a UPS (when there is a power outage). An approach like the one above was suggested by several people who already posted in the thread, and those suggestions came with some details for how to proceed, so that is the direction I have pursuedto this point.

But someone else suggested that a more securebut effective approach would be to run a cron job on the thin client that communicates with the server periodically using netcat and an inet service or ssh (with keys with restricted output-only commands or whatever). I don't currently have much of an idea how to implement that, but with a bit of an outline I may be game for a change of direction here. The same goes for your idea about a custom ssh client.

--John Hupp

On 10/25/2012 2:54 PM, Bettina Lapp wrote:
John,

imho it is not a good idea to have no root password on your ltsp server.
The root passwords (and accounts) in the ltsp server and the chroot have
nothing whatsoever to do with each other, there's no need to change your
root password on the server when you change it in the chroot. Only thing
you have to do is update the image after you changed anything in the
chroot, so it is applied when you reboot your client.

Anyway, I'm not sure (may have missed part of the discussion) why you
dont simply use public key authentication instead of passwords? Just
generate a key as root on the ltsp server, then copy the public key to
the authorized_keys file in the chroot (in /root/.ssh resp.
/opt/ltsp/i386/root/.ssh - make dir if not exist, update image).

You could also compile a custom version of the ssh client that takes the
password from an environment variable (which you can set in a shell
script, SSHPASSWD for example), only requires a few changes in the
source code. Let me know if you'd like a howto for this.

I imagine the problem with the known_hosts checking would persist, so
you'd have to disable that in any case... either way, I guess you
introduce a certain level of security risk.

regards, Bettina

Am 25.10.2012 19:56, schrieb John Hupp:
[...]
I made another run at accomplishing the same client shutdown with a
passwordless root account.  This time, instead of running "sudo passwd
-d root" in a terminal, I started a console (Ctrl-Alt-F1), logged in as
root with the simple password, and ran "passwd -d root."  The output, as
before, was "passwd: password expiry information changed."  But could
indeed log in to the console as root without a password.

I rebooted, deleted the root password in the LTSP chroot environment,
updated the client image, and rebooted again.

In a host terminal, I ran "ssh -l root <client IP> shutdown -h now," was
prompted for a password, and simply hitting the Enter key yielded
permission denied.  I also tried entering the simple password root had
before deleting it, and again, permission denied.  So while the result
is not quite the same as before, it still seems to qualify as "split
personalitysyndrome."

** But here was an interesting further development: If I logged into a
console as root and then ran the ssh shutdown command, it workedwith no
prompt for a password!! **

My actual goal here is, for a small LTSP network powered by a UPS, to
shut it down with a script in the event of a power outage.  It's not
clear to me that I now have something that will work, but I probably
have enough to try.

But the above split-personality behavior does beg for an explanation!

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Reply via email to