On 10/24/2012 5:15 AM, Richard Kweskin wrote:
Quoting John Hupp:
I was finally able to return to this.
Lance Levsen was the first to reply to my question, and indicated
the general approach thus:
What about a passwordless login setup in the chroot for root. Then
just a bash for loop?
$> for i in LIST; do ssh -l root $i shutdown -h now; done
where LIST is a list of hosts?
Rüdiger Kupper and David Burgess followed as below. But I am stuck
at the "passwordless login setup in the chroot for root." Following
https://help.ubuntu.com/community/RootSudo, I enabled the root
account (on the LTSP host and in the client image), but a password
was required.
I read in
http://manpages.ubuntu.com/manpages/hardy/man5/passwd.5.htmlthat if
/etc/passwd has an "x" in the password field for the user of
interest (and it does indeed for root), then the actual password
hash will be located in /etc/shadow, but that file does not exist.
I was imagining that I might delete the field in shadow to arrive at
a no-password state.
Rather than poke around in /etc/shadow and risk locking yourself out
by changing something other than the password hash there is a command
to replace a password with a "no password" password, but be warned:
(a) it is a horrific security hole to have the root user which does
not require a password
(b) only root may invoke it - not even may a user (other than root)
invoke it for itself!
(c) I have only used it in a straight forward configuration, i.e. not
in ltsp thin clients! So there is no guarantee what may ensue. Some
way toward guarding against undesirable conditions (e.g. one attempts
to login, there ensues an insistence to give a password, but there is
no valid password and a simple press of the enter-key is not accepted
either!) is to open a second console login as root there also (before
"blanking the password) from which one may recreate some root password
in case things go pear shaped.
Ok, with those caveats out of the way the command (as root) is
passwd -d root
Also if desired (only root may do it)
passwd -d user
<snip all the rest>
Richard
Interesting that you should mention the possibility of things going pear
shaped.
And I'm not saying they have, but they not have not gone by the book.
If at a console I log in as root and then run "passwd -d root," the
output is "passwd: password expiry information changed." Not the output
I would have expected.
If I then run "cat /etc/shadow," the password field is blank and I can
log in at a console as root with no password.
However, if I run my client shutdown command: "ssh -l root <client IP>
shutdown -h now," it requires a password and only accepts the
presumably-deleted password.
So it seems that two authentication mechanisms are somehow being
maintained and can develop a split personality.
I can return to the previously-established root password by logging in
as root with a blank password at a console and running "passwd root."
This heals the split personality, but I'm back where I started.
A Debian user had the same kind of experience with "passwd -d root" and
found that the problem was that PAM was set to use GNOME Keyring Daemon
instead of Unix Authentication, but he did not say how to check on or
configure that, and I have not been able to figure it out yet. That
post is here: http://forums.debian.net/viewtopic.php?f=5&t=52216
Anyone recognize what's going on?
------------------------------------------------------------------------------
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
