GSSAPI

Nico Kadel-Garcia nkadel at gmail.com
Fri Jul 18 11:33:17 EST 2014


On Thu, Jul 17, 2014 at 9:01 PM, Coy Hile <coy.hile at coyhile.com> wrote:
>
> On Jul 17, 2014, at 7:59 PM, Damien Miller <djm at mindrot.org> wrote:
>
>> On Thu, 17 Jul 2014, Douglas E Engert wrote:
>>
>>> I too am personally baffled why OpenSSH does not include the patch.
>>
>> We don't trust the attack surface the Kerberos/GSSAPI provides.
>
> What’s your justification for that?  I don’t see a larger attack surface in a kerberized environment compared to the wild west. In fact, I see a lesser attack surface in a purely kerberized environment (unless the host happens to be on the border) because you know everyone connecting has either already been authenticated by the KDC or will promptly get dropped on the floor.

Especially compared to the "oh, let me just leave my SSH private keys
without passphrases so I don't have to unlock them" practice that is
the commonplace in every environment I've dealt with since 1996, when
I first tried to compile ssh-1. This is re-inforced by the default
acceptance of ssh-keygen of passphrase keys, and *every environment*
I've ever audited has at least 20% passphrase free SSH private keys.
Often it approaches 90%. The technology of OpenSSH is pretty robust,
but the commonplace practices are often utterly, utterly horrid.
Educating user communities is too often seen as "not on task", and
"not part of the priorities", especially because it's often the CTO
and architects at a company who are most likely to ignore basic
security practices as a matter of policy.

The Kerberos tokens are a tremendous win over this, for robust
single-sign-on, for the ability to invalidate or reject keys at a
central access point, and for their ease of integration with SSL and
other technologies.


More information about the openssh-unix-dev mailing list