svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh

[Benjamin Kaduk]

On Thu, 5 Mar 2015, Slawa Olhovchenkov wrote:

> On Thu, Mar 05, 2015 at 10:11:43AM -0500, Benjamin Kaduk wrote:
>
> > On Thu, Mar 5, 2015 at 9:40 AM, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:
> >
> > Speaking as an upstream maintainer: don't use kerberized telnet.
>
> I am use this for test kerberos setup (check all setup correctly).

I use ssh to test kerberos setups (I think sshd has better error message,
for one).

The problem with using telnet to test the kerberos setup is that if your
kerberos setup works with telnet, you have the DES enctypes (weak
cryptography) enabled.  This means that the whole setup, even things other
than telnet, are suffering from the vulnerabilities of weak crypto.
Kerberos distributions have disabled DES by default for many years, now --
Apple has even completely removed the code for them from recent releases
of OS X!  Please see RFC 6649.

> > I use kerberized ssh all the time; please tell me more about how it is
> > broken (a new thread would be best).
>
> kerberized ssh broken in SSO mode: you can't do ssh login to

I have a very different idea of what "SSO mode" means: I run kinit on my
local machine and then use kerberos to authenticate to remote services.  I
should never type my password at something which is not a trusted local
binary.

> kerberized host (from outside world), input kerberos password and use
> kerberos ticket.

"input kerberos password and use kerberos ticket" doesn't make sense --
you are not using your kerberos ticket; you are using your password.  PAM
is going off and getting a ticket, sure (and hopefully validating it
against the host keytab to avoid the Zanarotti attack!), but it is
starting with your password.  That is completely at odds with how Kerberos
is intended to be used.

> This is issuse between PAM and ssh thread emulation.

It does seem likely that this sort of thing would be an issue with PAM,
yes.  I am not particularly motivated to look into it, though.

I do recall some issue where sshd in capsicum mode was not allowed to read
the keytab in order to verify the supplied Kerberos credentials, which
required using UsePrivilegeSeparation=yes instead of the default value
(sandbox).  Perhaps that would affect the password mode of operation as
well.

-Ben