Jim, 1) I think that rsh should be avoided on general principle. 2) I don't think local apps and NIS or even LDAP should be necessary in order to get shadowing capabilities.
Perhaps these ideals are unrealistic and I appreciate the old maxim about reinventing the wheel, but couldn't we just find some way totally around all the normal hurdles to make it simple and usable? I know that trading security for usability is not right and I don't intend to sacrifice security. With rsh, it was designed to allow one user on one machine to execute commands as another user on another machine, with all the password prompts required. But in our situation, we only have LTSP administrators (people who know the root password on the LTSP server) wanting to run commands on a machine whose only reliable account is root (not assuming LDAP/NIS authentication) and that isn't even password protected. So, do we really need to institute the whole password database system and authentication prompts to accomplish our goal? I don't think so. Ooh! What about this... What about starting a program with xinit as was recently suggested, but instead of starting x0rfbserver it starts a monitoring app? The app listens for a special key combination, say Shift-Alt-PrintScreen (customizable of course) that would start the x0rfbserver session. It would continue listening and stop the process when it receives the signal again, toggling back and forth. This ensures (pretty much) that the user agrees to the remote access. It admittedly goes against my hope that the user wouldn't have to do anything, but it's better than having to launch an app or switch to the text console to launch the x0rfbserver. The x0rfbserver could be rigged to only allow one connection. Assuming the administrator and the user are talking on the phone or are chatting online (somehow in real-time communication), the admin would connect as soon as the user issues the keystroke combination and no one would be able to hijack the session. If someone does manage to connect before the admin, the admin will immediately know it and tell the user to issue the keystroke combination again to shutdown the server. Damn, this isn't the clean solution I was hoping for. Maybe I'm just being stubborn about not using rsh... I honestly think it's not right for this situation, though. What about creating a special account on the workstations (in LTSP's passwd, group, and shadow files) for running remote maintenance commands? Make it userid 1 and call it 'admin' or something. Provide scripts that make it easy for the administrator of the main LTSP server to set the password on the account (and to change it at any time). Then you could rsh in without needing NIS or LDAP or anything complex. Is this stupid? It leaves the workstations open to repeat password attacks. I think this is going to be hard to avoid, though. And it's equally true for rsh with NIS/LDAP authentication. Thoughts? Am I confused about how rsh functions? Jason > The problem with running an rsh daemon on the > workstations is that it needs to know WHO is sending > the request to run something, and whether they are > allowed to or not. > > By turning on local apps, you enable NIS. That is how > the rsh daemon will validate that the "WHO" is a correct > user. > > An alternative to NIS might be LDAP, but we haven't gotten > that to work for local apps yet. > > In the past, some people have suggested just copying the > servers /etc/passwd file to /opt/ltsp/i386/etc, but I can > tell you very clearly that will NEVER be part of a > standard LTSP package. > > Creating a special-purpose daemon to handle this, in my > opinion, is just reinventing the wheel. Use what is already > there, and spend your time solving other more important > problems. > > But, I also invite you to challenge me on this. Maybe you've > got a better way. _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _____________________________________________________________________ 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.openprojects.net
