Re: ssh vs kerberos
This was my reply to a previously private message (which was later
forwarded to the list), so I guess it's appropriate to copy it here
for thread continuity...
----- Forwarded message from Matt Zimmerman <mdz@csh.rit.edu> -----
Date: Wed, 30 Jun 1999 01:06:56 -0400
From: Matt Zimmerman <mdz@csh.rit.edu>
To: Brian May <bam@snoopy.apana.org.au>
Subject: Re: ssh vs kerberos
On Wed, Jun 30, 1999 at 02:27:14PM +1000, Brian May wrote:
> Sorry to get picky - you do have to trust the remote host not to steal
> your password... (While this is also a problem when typing your password
> into kerberos, kerberos in the future could be altered to support OTP,
> one time passwords, etc).
Well, since the remote host has to know your password to authenticate you,
this is unavoidable. The good news is that you can limit its exposure to
just the two systems on either end of the connection. If I only use each
password at one site (and I do), then their knowledge of my password
doesn't get them any additional access.
> However, I guess it kerberos's advantage will always be that it is
> centrally administrated, where as ssh's advantage is that it isn't.
> People who don't like the organisations security policies, might be
> better of using ssh.
"There's more than one way to do it." I think that's a win for
everyone involved.
> >The idea of finding the realm and KDC via DNS is interesting...is
> Yes. I found the discussion on the comp.protocols.kerberos newsgroups.
> Please see attached messages - this shows the main proposal, I think. If
> you want me to post you the entire sub thread, then please let me know -
> I probably have missed a number of important points.
I should be able to follow up on the thread from there, thanks.
> >If you want to do RSA-based authentication, you can do that, and try to
> >protect your private keys, but it's not necessary. If you choose to do
> >this, you can also limit the privilege of a given private key (for example,
> >by only allowing it to execute a particular command).
> True. I tend to think though that time limited tickets are more useful
> then command limited keys - who uses command limited keys? I would be
> interested in knowing useful applications, in areas where it increases
> security...
I use command limited trust of RSA keys quite frequently for automated
jobs, for example, synchronization of directory hierarchies. I can do
this in ~/.ssh/authorized_keys:
command="rsync --server --sender -vrz /remotedir /localdir",no-agent-forwarding,no-X11-forwarding,no-pty,idle-timeout=1d <public key>
And allow a user to log in only to rsync a directory. Obviously, this
doesn't work very well with all programs (CVS, for example, can be run in
server mode this way, but it's apparently not difficult to leverage
shell access from CVS).
I never quite figured out how to get Kerberos tickets for automated
processes to access remote resources...
> >I have used Kerberos within an organization, and it seems to work well
> >for that (except for the lack of non-UNIX support), but I find that
> I think this might be improving - not sure though, as I usually just
> skip other messages about Windows support. I believe Microsoft has plans
> to support Kerberos in WNT5 and Windows 2000, whether it is going to
> be compatable that is something else entirely... See the kerberos FAQ,
> available from a link under http://web.mit.edu/kerberos/www/ for more
> information.
Thanks...I've seen more broken links that were supposed to lead to
Kerberos FAQs...
They appear to have a working (alpha-quality) library for NT, but no
application support so far. I personally don't use NT (*ever*), but
it's no fun to have to tell users that you don't have a way for them to
securely transfer files to a remote server. I should look into
ssh2's secure FTP facility; so far that's the only reason I see to
upgrade from 1.2.
> >Kerberos and SSH are not direct replacements for one another, and in fact
> >are quite useful together.
> I am not really convinced yet of this - they seem to have conflicting
> goals, eg kerberos goal of only entering your password once, but I will
> keep an open mind...
As you have noted, ssh supports the use of Kerberos tickets (among other
better-than-traditional-passwords methods) for authentication. Then,
on top of the Kerberos single-sign-on model, you get some extra bonuses,
like strong session encryption (I remember the kerberized telnet client
using DES for this...but it was a while ago), port forwarding (a lifesaver
for getting X sessions through a firewall/NAT), and on-the-fly compression.
[too many passwords]
> Arrgghh! This is one thing I really like about kerberos! How much it
> can help, I have still to find out.
Heh. There's no clear winner yet in the search for the dominant security
model, but I think we've learned an awful lot along the way. Hopefully
we'll have something stable and useful before too long.
--
- Matt
----- End forwarded message -----
--
- Matt
Reply to: