.k5login and non-kerberized ssh client

[Russ Allbery]

"Ryan Boyd" <rbisd at rit.edu> writes:

> Problem:
> I have a need for users to use their individual accounts to maintain
> websites owned by another account and I'm exploring different options to
> handle this.  For example,a website owned by 'wsowner' needs to be
> accessed by users 'user1','user2','user3' and more over non-kerberized
> SSH and SFTP clients.

> Possible solution 1:
> I have tried using a .k5login file in wsowner'shome directory and
> allowing access to 'user1 at DOMAIN.TLD','user2 at DOMAIN.TLD' and
> 'user3 at DOMAIN.TLD'.  'user1' can login over an ssh connection with a
> ssh.com ssh server and, from what I can tell, sshd acquires a kerberos
> ticket on behalf of the user.  'user1' can then, over a ssh.com ssh
> session, ksu to 'wsowner'.  I also presume that a user logged in as
> 'user1 at DOMAIN.TLD' could connect via a kerberized ssh or sftp client and
> access the 'wsowner' account directly.

> However, I would like some way for a non-kerberized ssh/sftp client to
> login directly as 'wsowner' using the credentials of, for example,
> 'user1 at DOMAIN.TLD'.  Is this at all possible?

Yes.  Enable PAM and then use the libpam-krb5 module from Debian.  You can
download the source, if you don't happen to be using Debian, from:

    <http://packages.qa.debian.org/libp/libpam-krb5.html>

(bottom of the left column, and you need both the .orig.tar.gz and the
patch .diff.gz).  I haven't tried to compile it on a non-Linux system and
the makefile isn't wonderful; I'm still negotiating with the new upstream
about accepting patches and generally cleaning up the package a bit.

You will need to add the "search_k5login" option in your PAM
configuration as this .k5login support is surprising to many people and
therefore isn't the default.

So far as I know, other krb5 PAM modules do not support this, which is one
of the reasons why I'm continuing to maintain and develop this PAM module
for Debian rather than switching to the one in Red Hat that everyone else
seems to be using.  It's a mandatory requirement for our environment.

(Note that weird things happen if two users listed in the .k5login file
both happen to have the same password, but I don't consider those weird
things to be true security vulnerabilities.  Anything that happens with
this module could be done intentionally without it.)

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>