Re: OpenSSH and pam_krb5
From: Darren Tucker (dtucker_at_zip.com.au)
Date: 04/16/04
- Previous message: Gareth Bromley: "SSH Tunnel logging"
- In reply to: Fredrik Tolf: "OpenSSH and pam_krb5"
- Next in thread: Fredrik Tolf: "Re: OpenSSH and pam_krb5"
- Reply: Fredrik Tolf: "Re: OpenSSH and pam_krb5"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 17 Apr 2004 07:41:29 +1000 To: Fredrik Tolf <fredrik@dolda2000.com>
Fredrik Tolf wrote:
> I'm running OpenSSH 3.7.1p1 on a number of GNU/Linux hosts, configured
> with GSSAPI and PAM authentication. The PAM configuration includes
> calls to the pam_krb5 module, which authenticates against a Krb5 KDC
> and is able to save the ticket using pam_setcred, which it also does
> when I log in through any program except OpenSSH. GSSAPI works
> beautifully, however, with credential forwarding and everything.
Yes, this is a known issue:
http://bugzilla.mindrot.org/show_bug.cgi?id=688
[quote]
Here's my understanding of what's going on. Currently this is only
known to affect Solaris, but it's possible the problem exists on other
PAM-using systems.
During pam_authenticate, the modules in question (pam_dhkeys, pam_krb5)
stash some private data using the pam_set_data() calls. In the normal
case, this data is present in a separate process (the "authentication
thread") and is lost when that process exits after completing the
authentication.
Later, when pam_setcred is called to establish the process credentials
(eg a PAG for AFS or the stored DH keys, however they are stored), that
private data is not available to module, so the credentials are not
established.
The data stored by pam_set_data is completely inacessible to the
application (ie sshd). If is was stored via pam_set_item, pam_putenv or
the normal environment space, it can be copied to the main sshd process
(and in 3.8 and up, it is).
Currently, the only known workaround is to enable the use of POSIX
threads, as Paul discovered. This is because the module-private data is
stored in the same address space as the main sshd, and thus survives the
termination of the "authentication thread". It is then copied to the
child forked to run the user's shell an is available to the
pam_setcred() calls in session.c.
Note that enabling threads opens up sshd to any number of races with any
PAM module, so is not recommended unless absolutely necessary and you
better hope your PAM modules are thread-safe. Thread support in sshd is
currently a necessary evil for these cases. Once there is a better
solution, thread support becomes an *unnecessary* evil, and will be removed.
[/quote]
--
Darren Tucker (dtucker at zip.com.au)
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.
- Previous message: Gareth Bromley: "SSH Tunnel logging"
- In reply to: Fredrik Tolf: "OpenSSH and pam_krb5"
- Next in thread: Fredrik Tolf: "Re: OpenSSH and pam_krb5"
- Reply: Fredrik Tolf: "Re: OpenSSH and pam_krb5"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
