I've been trying to get OpenSSH to correctry use pam_krb5 with challenge-response auth ("ChallengeResponseAuthentication yes" in /etc/ssh/sshd_config) with no success. It turned out to be sort of a problem with OpenSSH and PAM relations (see http://bugzilla.mindrot.org/show_bug.cgi?id=688). Additionally, latest version in portage (v 20030601-r1) has a problem with cred cache file permissions and needs a patch (available on SourceForge btw). So, after a couple of hours I found alternative (and actively maintained - current version 3.3 is dated 2007-01-25!) distribution of pam_krb5 which forked from the one in portage very long ago. I made an ebuild, installed and successfully tested it under ~x86 using mit-krb5 1.5.2 (can't say anything about Heimdal). Challenge-response worked and permission problems were all gone. The only problem is that the new module doesn't support AFS, but there is another PAM module (URL http://www.eyrie.org/~eagle/software/pam-afs-session/). I'll try to make an ebuild for that also. So here's my first (crappy) ebuild. Please send any comments and improvement requests, I'll try to fix everything. I couldn't find appropriate name for it (because it is different code from mit_krb5, but compatible), so I simply named it mit_krb5_new.
Created attachment 108160 [details] Ebuild for new pam_krb5 module version 3.3
Sorry, I meant "pam_krb5" and "pam_krb5_new" in the last sentence.
Do you volunteer to proxy-maintain this? Otherwise, pam_krb5 will be most likely removed from the tree altogether instead of introducing yet another fork of a thing that none of Gentoo developers has a clue about and so was unmaintained for ages.
I'm not very fond of English, sorry - what do you mean by "proxy-maintain"? If you mean make and test ebuilds when new versions come - then sure, I will do it. I have some servers using it on x86 and amd64-multilib. The only major problem with this package is its name. pam_krb5_new is imho a bad name, and stripping the "_new" part is wrong. Can someone give me an advice? PS: pam_krb5 is a module for PAM (obviously) which can transparently authenticate via Kerberos and get tokens from KDC to client who accessed any service with PAM support. It eliminates the need for special support for Kerberos in login, ssh and other services.
Alex, that is part of it. The main part is helping with bugs. When bugs get filed on bugzilla, kerberos team will need help to solve those bugs. Additionally, the proxy maintainer keeps track of what's happening upstream so that issues can be anticipated, etc.
Well, I'll try, so count me in :) I'm available via compot.ru mail listed here, on unikmhz <AT> gmail #DOT# com and ICQ UIN 33097323 (an IM network that is popular in Russia). You can call me Unik - everyone calls me like that since i was 7 y.o. :) . PS1: Ebuild works on ~amd64. PS2: Can anyone test it with Heimdal (and possibly with PKINIT - SmartCard stuff - details in manpage and/or homepage)? PS3: As a side note, I'm currently in process of setting up OpenAFS with pam_afs_session, so wait for another ebuild and a report. PS4: Do you need a patch to make old pam_krb5-2003* work (set up file permissions correctly)?
Version 3.4 is out. Ebuild works unmodified.
I can confirm that the ebuild for this newer version of pam_krb5 is working on a somewhat recent gentoo system. I compiled the pam_krb5 version 3.4 using app-crypt/mit-krb5-1.4.3-r3 without any issues. I have only tested ssh access, but that seems to be working flawlessly. The only minor issue that I encountered was due to the old 20030601-r1 version also having the ~x86 keyword, and my system wanted to install that version after specifying only ~x86 in package.keywords for this ebuild. I would vote for masking the two older versions (1.0-r1 and 20030601-r1) and moving this newer version in their place.
I would also vote for this solution, together with pam-afs-session, which can be found in bug #160082.
I tried this on an amd64 machine with heimdal and it compiled and worked fine. I also tried it on x86 with heimdal and it worked there too. I'm using it with pam-afs-session too. I'm using version 3.4 with version 1.1 of pam-afs-session. My kernel is 2.6.18-gentoo-r6. And openafs is version 1.4.3-rc1. I tested the following cases: - logged in with login at console prompts for password and gets a ticket, a new PAG and an AFS token. - logged in with openssh on a machine without a ticket. It prompts for a password and I get a ticket, a new PAG and an AFS token. - logged in with openssh on a machine with a forwardable ticket. It doesn't prompt for a password and I get a ticket, a new PAG and an AFS token. - used scp to copy a file in AFS from a machine that doesn't have a ticket. It prompted for a password and the file copied with no problems. - used scp to copy a file in AFS from a machine that has a ticket. It didn't prompt for a password and the file copied with no problems. - logged in using gdm which prompts for a password and I get a ticket, a new PAG and a AFS token.
(In reply to comment #10) > I tried this on an amd64 machine with heimdal and it compiled and worked fine. > I also tried it on x86 with heimdal and it worked there too. I'm using it with > pam-afs-session too. I'm using version 3.4 with version 1.1 of > pam-afs-session. My kernel is 2.6.18-gentoo-r6. And openafs is version > 1.4.3-rc1. I use MIT Krb5 and the combination of works fine for me for some of the cases below. > I tested the following cases: > - logged in with login at console prompts for password and gets a ticket, a > new PAG and an AFS token. Me too. > - logged in with openssh on a machine without a ticket. It prompts for a > password and I get a ticket, a new PAG and an AFS token. Not for me, but I guess it's a problem in my sshd_config. Would you mind sending me the relevant parts of yours via p.m.? > - logged in with openssh on a machine with a forwardable ticket. It doesn't > prompt for a password and I get a ticket, a new PAG and an AFS token. > - used scp to copy a file in AFS from a machine that doesn't have a ticket. > It prompted for a password and the file copied with no problems. > - used scp to copy a file in AFS from a machine that has a ticket. It > didn't > prompt for a password and the file copied with no problems. See above. > - logged in using gdm which prompts for a password and I get a ticket, a new > PAG and a AFS token. kdm doesn't work (out of the box) when $HOME is inside AFS, so I used qingy, which works fine. Another problem I have is that (maybe due to improper pam setup), after switching to this pam_krb5 module and pam-afs-session, I can login as root w/o password.
(In reply to comment #11) > (In reply to comment #10) > > - logged in with openssh on a machine without a ticket. It prompts for a > > password and I get a ticket, a new PAG and an AFS token. > > Not for me, but I guess it's a problem in my sshd_config. Would you mind > sending me the relevant parts of yours via p.m.? I'm sending you an e-mail with my sshd config information, but basically I think it works because I'm using GSS-API. > > - logged in with openssh on a machine with a forwardable ticket. It doesn't > > prompt for a password and I get a ticket, a new PAG and an AFS token. > > - used scp to copy a file in AFS from a machine that doesn't have a ticket. > > It prompted for a password and the file copied with no problems. > > - used scp to copy a file in AFS from a machine that has a ticket. It > > didn't > > prompt for a password and the file copied with no problems. > > See above. > > > - logged in using gdm which prompts for a password and I get a ticket, a new > > PAG and a AFS token. > > kdm doesn't work (out of the box) when $HOME is inside AFS, so I used qingy, > which works fine. I haven't used either kdm or quigy. So, I don't know for sure why kdm doesn't work. But, you might need to set your AFS permissions on your $HOME directory to system:anyuser l or rl in order to get KDE to work. It probably is looking for a file in your home directory before it gets a token to access it. If you can figure out what the file is, then you'll probably want to put it in another directory that has rl for system:anyuser and symlink it back to your home dir. And, also, you'll want to be careful not to give system:anyuser rl to any new directory you create. > Another problem I have is that (maybe due to improper pam setup), after > switching to this pam_krb5 module and pam-afs-session, I can login as root w/o > password. > This sounds like a pam config problem. Above your "auth require pam_krb5.so" line you should have a line like: auth sufficient pam_unix.so in your /etc/pam.d/system-auth file. That way it will look in your /etc/passwd file for root's password and if entered correctly stop authenticating. I'm using LDAP for my user database too. So, for me that also means that the userPassword attribute needs to be "*" for all my users. That way it fails pam_unix and goes to kerberos for authentication.
Hello all, the bug described here with openssh + the current pam_krb5 also took me a lot of time until I found out that it is broken. I tried out the new pam_krb5 that is suggested here and it works like a charm.. Full vote to put it into portage instead.. :)
*** Bug 171920 has been marked as a duplicate of this bug. ***
Upstream version 3.5 was released on 4/10. Attached ebuild works perfectly after a rename. This version installs just fine using current stable mit-krb5, and works for openssh logins. Upstream changelog includes: pam-krb5 3.5 (2007-04-10) Don't try to chown non-FILE ticket caches, which among other things breaks using pam-krb5 with Heimdal KCM caches. Thanks, Jeremy Jackson. When logging session deletion via pam_setcred or pam_close_session, don't look for the username in the PAM context after it's been freed. Thanks, Markus Moeller. Map more Kerberos status codes to PAM status codes for authentication errors.
*** Bug 26509 has been marked as a duplicate of this bug. ***
version 3.5 also compiles and works with heimdal both on ~x86 and ~amd64
Works on amd64, even with heimdal-1.0.1 (newest one)
Created attachment 131353 [details] pam_krb5-3.6.ebuild clean up.
All my problems mentioned in comment #11 are solved, so I would also vote to finally put this into portage, together with pam-afs-session.
I can confirm that version 3.6 compiles and works normally on x86 using mit-krb5 1.5.3. I would like to vote again to put this into portage.
Created attachment 133208 [details] pam_krb5-3.8.ebuild
Created attachment 133694 [details, diff] Patches to pam_krb5-3.8 (In reply to comment #22) > pam_krb5-3.8.ebuild I tried to compile your ebuild on a stable x86 system with heimdal-0.7.2-r3. I found the attached modifications useful. They solved these three issues: 1. compiler warning: missing const keyword. 2. compiler error: krb5_kt_cursor is not a pointer type with my heimdal. 3. QA notice: missing header files for getpwnam; pam_modutil_getpwnam does not seem to be part of sys-libs/pam-0.78-r5 With these modifications the ebuild compiles cleanly. Now I'll have to decide whether to risk merging it to a live system.
As I wrote on bug #199370, we'd be willing to proxy-maintain this. We use pam_krb5 on many hosts with AFS, AFAIK with the heimdal libraries, on amd64 and x86, but if desired we could create a test host with the MIT libs. Is anyone else interested? If this got dropped from portage or remained unmaintained we'd have to maintain it ourselves anyway, so there is little additional workload and much additional testing if we proxy-maintain. Currently we use pam_krb5-2.2.21 and everything* works, without the need for additional session plugins (eg. afs-session). Our KDC is a Windows AD. * What doesn't work is passwordless ssh login via Kerberos ticket with an AFS home, due to a bug in heimdal. You can login, but you don't get AFS access.
(In reply to comment #24) > As I wrote on bug #199370, we'd be willing to proxy-maintain this. We use > pam_krb5 on many hosts with AFS, AFAIK with the heimdal libraries, on amd64 and > x86, but if desired we could create a test host with the MIT libs. Is anyone > else interested? We are using pam_krb5 with nfsv4 and MIT kerberos. For now, we didn't have any problems with this ebuild and we contributed also a bugfix to the original author. Best regards, Chris
(In reply to comment #23) My patch has been accepted upstream, minus the sys/types.h include directive. The current release, 3.9 from 2007-11-13, does include these modifications. See http://www.eyrie.org/~eagle/software/pam-krb5/ (In reply to comment #24) Thomas, are you aware that the 2.2.21 version you are currently using is probably a completely different branch of the module, maintained by a different person? At least that is my understanding of the current situation. 2.2.21 (bug 196296, bug 199370): Author: Nalin Dahyabhai URL: http://people.redhat.com/nalin/pam_krb5/ AFS: support included 3.9 (this bug here): Author: Russ Allbery URL: http://www.eyrie.org/~eagle/software/pam-krb5/ AFS: separate module
*pam_krb5-3.9 (04 Dec 2007) 04 Dec 2007; Doug Klima <cardoe@gentoo.org> metadata.xml, +pam_krb5-3.9.ebuild: Add pam_krb5 from Eyrie.org
(In reply to comment #8) > I would vote for masking the two older versions (1.0-r1 and 20030601-r1) and > moving this newer version in their place. Now that 3.9 is in portage for testing, I think it is time to mask 20030601-r1. 1.0-r1 is stable, and compares less than 3.9, so I guess it should stay for now. 20030601-r1 is rather outdated, confuses version numbers, and will prevent people from testing 3.9 unless they explicitely request that version.
(In reply to comment #28) > Now that 3.9 is in portage for testing, I think it is time to mask 20030601-r1. > 1.0-r1 is stable, and compares less than 3.9, so I guess it should stay for > now. 20030601-r1 is rather outdated, confuses version numbers, and will prevent > people from testing 3.9 unless they explicitely request that version. 1.0-r1 is as outdated as the other. And there's also 2.2.6. However, I would like to see one final addition: an afs USE flag to automatically pull in pam-afs-session. After this all other versions could (or even: should) be removed in favour of Russ Albery's modules, which seem to be the only ones which are currently actively maintained.
*pam_krb5-3.9 (04 Dec 2007) 04 Dec 2007; Doug Klima <cardoe@gentoo.org> metadata.xml, +pam_krb5-3.9.ebuild: Add pam_krb5 from Eyrie.org Closing; anything else -> a new bug.