Re: OpenSSH and pam_krb5

From: Darren Tucker (
Date: 04/17/04

  • Next message: "Patch metrics for various versions of SSH"
    Date: Sun, 18 Apr 2004 01:05:42 +1000
    To: Fredrik Tolf <>

    Fredrik Tolf wrote:

    > Darren Tucker writes:
    > > Good luck, fixing this looks hard when using keyboard-interactive
    > > because PAM deliberately hides the information sshd would need to
    > > export. I have a couple of possibly viable ideas, I'll attach them to
    > > the bug when I rewrite the details a bit.
    > Precisely what I was thinking as well... I was merely hoping that
    > maybe PAM specifies that the private data must be contained within a
    > well-defined memory space in order to make it copyable. Unfortunately
    > I seem to have lost my PAM source for the moment, so I can't verify
    > that. I do have my doubts, though... :-)

    I looked at this option. pam_set_data() stashes its stuff in the
    pam_handle which is a "blind type". With the published API, you can't
    look into it, you can't even tell how big it is. Any code that can do
    these things is going to be relying on undocumented internals and will
    likely be fragile and non-portable.

    > If that fails, I'm kind of hoping that it might be possible to
    > "switch" functionality so that the main process does the PAM
    > authentication. I have my doubts about that, too, though...

    That sounds like the "PAM inversion" idea we've kicked around privately.
      Normally, sshd forks and the child runs the PAM functions while the
    parent talks to the client (or monitor with privsep). The idea is that
    the after the fork, both parent and child share all the same
    descriptors, so in theory it would be possible to run the PAM functions
    in the parent and have the child talk to the client temporarily. (I'm
    going to take a swing at writing this after 3.8.1p1 ships, but don't let
    this stop anyone else saving me the work :-)

    There's a couple of wrinkles identified so far:
    a) There could be a rekey during this process, in which case when the
    parent returns to normal it would still have the old keys. (This could
    probably be fixed by using mm_send_keystate).
    b) If the PAM modules crashes it will kill your entire session. (At the
    moment it logs a failure and continues). This is probably not a
    c) You would need to be very careful making sure the child process
    wait() handling is right for all of the cases.

    Another option would be some kind of coroutine implementation but that
    is likely to be hideous and possibly non-portable. (See Simon Tatham's
    description at [1], it's an extremely clever hack but you might want to
    take some anti-nausea pills before following the link).

    > Yeah, I managed to find that out eventually, only on GNU/Linux it's
    > -lpthread (singular). I take it this is a rather experimental feature,
    > considering how concealed it is?

    Call it "grudging support". It's potentially dangerous if any of your
    PAM modules are not thread-safe. Unfortunately, right now it's also the
    only know way of getting setups like yours to work, so it's still there.
      You have to know you need it, rather than random people doing
    "configure --with-pthreads" simply because they read in a magazine once
    that threads are cool.

    > > There's also a compile-time error in that configuration that is fixed in
    > > either 3.8p1 or the soon-to-be-released 3.8.1p1.
    > Really? It worked perfectly well for me. I guess it will have to do if
    > I really can't find another solution. Thank you very much for helping
    > me with this - my pam_krb5 module finally works, even if it's using an
    > experimental feature.

    It might have been introduced in 3.8p1 and (will be) fixed in 3.8.1p1.


    Darren Tucker (dtucker at
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
         Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  • Next message: "Patch metrics for various versions of SSH"