[33015] in Kerberos

home help back first fref pref prev next nref lref last post

Re: GSS_C_NO_NAME for desired_name?

daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Jan 1 13:42:32 2011

From: Greg Hudson <ghudson@mit.edu>
To: Brian Candler <B.Candler@pobox.com>
In-Reply-To: <20110101164855.GA4374@talktalkplc.com>
Date: Sat, 01 Jan 2011 13:42:22 -0500
Message-ID: <1293907342.2456.241.camel@ray>
Mime-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

On Sat, 2011-01-01 at 11:48 -0500, Brian Candler wrote:
> That is: if someone broken into httpd, and it was using a shared keytab
> which also contained the sshd key, then they'd be able to go fetch (and
> abuse) the sshd key.  And on the flip side, a user who has a legitimate
> ticket for HTTP/foo would also be able to get a legitimate ticket for
> host/foo, so there's no additional problem if sshd happens also to accept
> the HTTP/foo ticket.

The problem comes when you have a host keytab containing host and HTTP
keys (maybe as an artifact of how the site deploys keys to hosts), and a
httpd keytab containing only the HTTP key.  With "strict acceptor check"
behavior in sshd, this configuration doesn't allow httpd access to sshd.
Without strict acceptor checks, it might.


________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post