Six Kerberos/OS X/SSH observations and questions

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I've installed MIT Kerberos 5 to provide single signon among the three
boxes in my home network. Given that I'm a casual user I'm rather
proud of my little setup, complete with regularly-updated slave KDC as
backup. It's quite neat using Kerberos tickets to authenticate console
logins, sudos, and SSH logins between my two Fedora Core 3 Linux

A few observations and questions:

1) The third box is an Apple iBook running OS X 10.3.8. I've
managed, thanks to documentation and software found at Brandeis and
Georgia Tech/Michigan, respectively, to integrate Kerberos
authentication into its GUI box and sudo. (How Apple can brag about
10.3's 'extensive Kerberos support' and not include either a) an
equivalent to Red Hat Linux's 'authconfig' to easily Kerberize these
tools, and b) a Kerberos PAM module, is beyond me. Come to think of
it, a is probably due to b.) It took me quite a while to figure out why
Kerberos SSH connections *didn't* work to and from the iBook; for
others' benefit, it's due to the change in OpenSSH 3.8 from gssapi to
gssapi-with-mic. The OS X OpenSSH is still at 3.6.1p1 (and Fink's
version is 3.7.1p1), while Fedora's OpenSSH is 3.9p1.

2) It took me even longer to figure out that what I would
think of as Kerberos ticket-based, interactive-less authentication is
called 'GSSAPIAuthentication', while 'KerberosAuthentication' is
not. (Although needing to enable the former to get my Kerberos-based
logins to work at all in my network ought to have given me a clue.)
This could have been explained much more clearly in the relevant
sections of the sshd_config man page; a vague allusion to
'PasswordAuthentication' in the 'KerberosAuthentication' paragraph
really isn't sufficient to explain the whole story, in my view.

3) I've had public key SSH logins working well between all three
boxes for some time. Given that fact, I wonder if I should even bother
to switch to Kerberized SSH logins in the first place on any of my
boxes. Put another way, is there any reason to believe that using a
Kerberos ticket to authenticate myself in OpenSSH is "better" than a
public key? Or vice versa?

4) When I take my iBook on the road I'd like to, assuming Internet
access is available, still use my home KDC to authenticate my logins
and sudos. I can easily expose the proper ports to the outside world
through my firewall (in fact, it'd probably be safer to point them and
only them toward my backup KDC, which otherwise is otherwise invisible
to the outside world and has many fewer services running on it). Are
there any particular security issues, other than the usual "expose as
few services as possible" advice, I need to keep in mind if I do this?
Yes, I could just use the NetInfo password to log in instead (and, of
course, this will be what I do when network connectivity isn't
available) but again, I'd like to do this "right" and take advantage
of the infrastructure I've built if not unreasonable.

5) An annoyance related to scenario 4 is that since in OS X networking
(possibly just wireless, as I don't use Ethernet with my iBook) isn't
enabled until after a graphical login, this means I have to log in
using only the NetInfo password the first time after any reboot. How
can I get networking turned on without a initial graphical login?

6) The general advice I see on the issue of whether the NetInfo and
Kerberos passwords should match is that this is a bad idea. Why? In
scenario 5) (or scenario 4 without network connectivity) I would think
I'd *prefer* to only have one password to remember that will work
whether the login process succeeds in connecting to a KDC or instead
falls over to NetInfo (Or is the other way around?). I'd also prefer
that when I change my Kerberos password my NetInfo password also
changes, and perhaps even vice versa. What are the horrible downsides
to such password synchronization?

Read my Deep Thoughts @ <URL: PERTH ----> *
Cpu(s):  6.9% us,  3.0% sy,  0.7% ni, 82.3% id,  6.1% wa,  1.0% hi,  0.0% si
Mem:    515800k total,   510976k used,     4824k free,     5528k buffers
Swap:  1052216k total,    20052k used,  1032164k free,   176340k cached

Re: Six Kerberos/OS X/SSH observations and questions

Entity Yeechang Lee spoke thus:

Quoted text here. Click to load it
Writing on behalf of comp.sys.mac.system I'd be curious to know what are
some of the advantages of your plan over the OSX builtin SSH authentication?

Maybe you could explain.

-- Gnarlie's Applescript page: /

Re: Six Kerberos/OS X/SSH observations and questions

Quoted text here. Click to load it

Kerberos has the following advantages, which may or may not be of interest
in your situation:

 * No need to copy keypairs around to different systems.  Any system that
   uses Kerberos and has the right SSH installed can be used to
   authenticate to any other system that uses Kerberos authentication
   without requiring any additional key exchange.  If you're the only
   user, the amount of required configuration may be roughly equivalent;
   if there are a lot of users, Kerberos becomes easier.

 * Central management.  If you want to revoke the access of someone who
   has been using public key pairs for authentication, you have to remove
   their authorized key or their account from every individual system.
   With Kerberos, you can deactivate their account centrally and know that
   all access will be shut off within the ticket expiration lifetime.

 * SSH public key authentication only works for SSH.  If you have other
   Kerberized services, you may need to obtain a Kerberos credential
   anyway, in which case using that for SSH as well simplifies matters

 * Ticket forwarding.  Kerberos can allow you to authenticate only once
   and then pass your credentials to other systems and then use those to
   log on to other systems, as well as use those same Kerberos credentials
   to access other Kerberos-protected services.

Russ Allbery (             <

Re: Six Kerberos/OS X/SSH observations and questions

Russ Allbery wrote:
Quoted text here. Click to load it

And these build together to help you put together a single-sign-on
environment.  You authenticate once on your laptop, and then you can use
that one authentication event to access email, access remote servers,
get an AFS token (if you use AFS) for accessing files, etc.

As far as I know, SSH keys can't do that for you.

Site Timeline