Possible security flaw in OpenSSH and/or pam_krb5

Douglas E. Engert deengert at anl.gov
Sat Jun 18 07:13:25 EST 2005



Stephen Frost wrote:

> * Damien Miller (djm at mindrot.org) wrote:
> 
>>We do get PAM, we just don't feel the need to rewrite our application to
>>cope with its terrible interface. What we have works with the vast
>>majority of PAM modules and the module that does regularly cause
>>problems (pam_krb5) replicates functionality largely integrated into
>>OpenSSH anyway.
> 
> 
> This caught me slightly off-guard so I'd like to just double-check...
> As far as I'm aware it's not possible to duplicate what pam_krb5 does
> (takes a password, gets a TGT and a host/<fqdn> for the user and dumps
> it into their KRB5CCACHE) with OpenSSH today.

OpenSSH had direct Kerberos support, if you add --with-kerberos5=path
to configure and can compile against MIT or Heimdal. But the nice thing
about using it via PAM is that you can use a vendor's version of OpenSSH
that may not have been compiled with the --with-kerberos5, and add Kerberos
later via PAM.

(OpenSSH also had GSSAPI for Kerberos.)

> 
> Thinking about it, I don't see any particular reason why that *couldn't*
> be coded into sshd, and it would nicely get around the problems pam_krb5
> and ssh have today.  I expect there would need to be an option to
> enable/disable it since I'm sure some people have setups similar to me
> (one machine allows passworded logins, everything else demands
> Kerberos).

Has the KerberosOrLocalPasswd yes|no options too.

> 
> Am I wrong in my assumption that OpenSSH hasn't got such an option
> today, and if not, is this an indication that the OpenSSH team would be
> willing to consider a patch to add that functionality directly to
> OpenSSH?  Anyone else interested in this besides me?  Personally I'm not
> exactly a big fan of the seemingly often interaction problems between
> OpenSSH and pam_krb5 and this might resolve the problems once and for
> all...

The code is there, and works, but I would be in favor of not using it
but using PAM instead as it uses Kerberos non standard API code out of
sshd, and in to seperate modules like pam_krb5 (or gssapi). The PAM code
is getting better, and as pam_krb5 is used by other login functions, like
login, or gdm, or dtlogin, xlock, xscreensaver, pam_krb5 will still be around.




> 
> 	Many thanks,
> 
> 		Stephen
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




More information about the openssh-unix-dev mailing list