Re: Elimination of ssh chatting - Possible solution

Catching up on some old email, and I wanted to throw out a thought for
discussion, which is along the same lines of rethinking ldm:

Does ldm really need to start the X server?  Can we not simply start
an X server in the screen script with xinit and run ldm as the sole
program on the root window?

The reason I throw it out there is that is ldm is really mostly a
graphical front-end to "ssh -X....", then perhaps there would be added
flexibility gained in treating it as simply a program (or, as in
Scott's idea, a collection of programs).  I am not sure if this would
help solve some of the woes with xauth, but it would, at least, add
some flexibility to, say, run ldm in an Xnest server or some other X
proxy server or some such.  It would also trim down the code quite a
bit, and ldm can focus a great deal more on the ssh chatting and such.
 Is there an intrinsic value to having ldm start the X server?

-Gadi


On Mon, Mar 17, 2008 at 12:44 PM, Scott Balneaves
<sbalneav-TFIdw2FCnGjMR/[email protected]> wrote:
> Hello all!
>
>  So, I've got a fix for properly handling xauth when LDM_DIRECTX is specified,
>  and I'll push some changes up to my branch shortly.
>
>  However, I sat down on the weekend, trying to sort out the whole text versus
>  graphical login via ssh mess/issue.  Here's a statement of the problem
>  for those interested.
>
>  Currently, what we do, after we collect the userid and password from the
>  greeter, is spawn off an SSH session.  We need to look at the text
>  output of this ssh session, to look for the "password: " prompt, and supply
>  the password.  Additionally, if there's been a password expiry, we need
>  to handle the "enter new password" etc. conversation.
>
>  But why?
>
>  Well, the problem is, even though there's a mechanism within ssh to handle
>  asking for a password graphically (via the ssh-askpass mechanism), this
>  doesn't extend to changing passwords.  Here's the reason why:
>
>  In the sshd's session.c file, around the 1400 line mark, you've got a function
>  called "do_pwchange", which execl's the passwd program (snippeted fyi):
>
>  static void
>  do_pwchange(Session *s)
>  {
>  ...
>  #ifdef PASSWD_NEEDS_USERNAME
>         execl(_PATH_PASSWD_PROG, "passwd", s->pw->pw_name,
>             (char *)NULL);
>  #else
>         execl(_PATH_PASSWD_PROG, "passwd", (char *)NULL);
>  #endif
>  ...
>
>  Fair enough, and a reasonable thing to do.  The problem is, it's not really
>  what we need.
>
>  Here's what would be really cool.
>
>  The greeter, per se, would disappear.  We'd have 3 small programs running on
>  the "greeter" screen:
>
>  1) a small program that would allow the user to pick menu options, such
>    as the language and session, reboot, etc. like we do now.  It could
>    set xprops for communication.  It would be at the bottom left of the
>    screen like now.
>  2) a small program that just displays the workstation name, clock, and any
>    other info we want to display on the lower right.
>  3) An ssh-askpass like program that would run first in the centre of the
>    screen to ask the userid, then exit.  It's name would then be passed
>    to ssh via the ssh-askpass mechanism, so that the ssh session could then
>    call it, when the ssh to the server is initiated.  It would ask for the
>    password.
>
>  The "background" image would simply be set via xsetbg or the like.
>
>  Now, we'd eliminate the text login entirely (something I know ogra would like
>  to see) and simply do an ssh to start the session via Xsession.  "But what
>  happens if the password expires, Scott?"  I hear you say, well, here's where
>  it gets a bit tricky.
>
>  What's needed are 2 things:
>  1) The ability to specify to sshd a different program other than "passwd" for
>    changing expired passwords.
>  2) An ability to allow ssh to do X forwarding even when a password is expired.
>    Currently, if your password's expired, X forwarding doesn't work.
>
>  What would then happen is, if you're password's expired on the server, instead
>  of sshd calling the "passwd" program, it would call "gtk_passwd" or "kpasswd"
>  or the like, that would allow you to change the password in a graphical manner,
>  then exit.
>
>  This would mean that we simply don't have to worry about screen-scraping the
>  ssh session at all: simply ssh the Xsession, and if your password's expired,
>  then ssh will force you to change it, and you'll simply log in again.
>
>  Simple, no?
>
>  Well, maybe yes, maybe no.
>
>  What this requires is 2 things, both modifications to sshd:
>
>  1) We'll need a new option to sshd_config, call it
>    PamPasswordProgram %s
>    or similar, to allow us to specify a program other than passwd for
>    handling expired passwords.  And:
>  2) An option like:
>    ForwardXWithExpiredPassword (y/n)
>    Which would allow us to control the X forwarding with expired passwords.
>    Default behaviour would be as it is now, as "n"
>
>  Since these changes are fairly different from default sshd behaviour, we'll
>  need a separate sshd running on a separate port, and a separate sshd
>  config file, in /etc/ltsp, with the options overridden like we want.
>
>  So, in short, modifications to sshd.
>
>  Eeek.
>
>  So, the question becomes, how do we go about this.  My first instinct would
>  be to try to approach one of the ssh authors, and see if we could make this
>  fly.  Instinctively, it would strike me as being a logical extention to the
>  ssh-askpass mechanism, and something they might be receptive to.  But I'm
>  not sure.
>
>  What do people think?
>
>  Scott
>
>  --
>  Scott L. Balneaves | "There are many causes I am prepared to die for,
>  Systems Department |  but no causes I am prepared to kill for."
>  Legal Aid Manitoba |    -- Mohandas Karamchand Gandhi
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  _____________________________________________________________________
>  Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
>       https://lists.sourceforge.net/lists/listinfo/ltsp-developer
>  For additional LTSP help,   try #ltsp channel on irc.freenode.net
>

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net