>>>>> "Jeffrey" == Jeffrey Altman <[EMAIL PROTECTED]> writes:
Jeffrey> If Kerberos is used for authetnication then no password is sent to the
Jeffrey> server. If Kerberos is not used for authentication then the password
Jeffrey> is sent to the server over an encrypted connection. BUT the password
Jeffrey> is not used to perform Kerberos authentication on the server.
Ummm... what sshd are you talking about? 1.x sshd's of recent vintage can
perform password auth against krb5 on the server. I have no idea what's in
the 2.x codebase.
As for the original question, in _no_ case will ssh send passwords in the
clear (OK, a white lie - it will if you're using the null cipher, which is
disabled by default). The differences are:
- who can see the actual password. If your ssh client gets the krb5 ticket,
the server never sees your password, and so a malicious server can't re-use
your password. Of course, if you forward your ticket, it could do similar
things for krb5-enabled services.
- the above mentioned forwardable tickets issue. If your site security
policy forbids forwardable tickets, and you need to be authenticated to log
in (e.g. AFS home directories), you need to have the server get you a
ticket.
- who has to be able to talk to the KDC. This matters in firewalled/NATted
environments.
- where config files are maintained. Obviouly, the client has to have some
means of knowing where the KDCs are. Since no client I know of uses any kind
of service location protocol (for any number of reasons, including
security), there's a config maintainance issue.
--
Carson Gaspar -- [EMAIL PROTECTED]
Queen Trapped in a Butch Body
