Pending OpenSSH release, call for testing.

[Markus Moeller]

Darren,

We have systems which are multihomed for virtualisation, but run only one sshd.
You can connect to any IP-address and should be authenticated with
gssapi/kerberos. So the client will ask for a principal host/virt-ip-X and the
server has to have an entry for this in the keytab and has to select the right
key by determining the hostname from the connection IP-address. There is no other
way to this (except with GSS_C_NO_NAME, which I haven't tested)than having a
keytab entry per interface, which isn't a problem as gss_import will select the
right one. Kerberos depends on a one-to-one mapping of hostname to ip-address.
You should never have a hostname with two ip-addresses, Kerberos won't normaly
work.  


Regards
Markus
 

On Mon Sep 13 16:14 , 'Douglas E. Engert' <deengert at anl.gov> sent:

>
>
>Darren Tucker wrote:
>
>> Markus Moeller wrote:
>> 
>>> Could you add to this release a patch which allows gssapi to be used 
>>> on a multihomed server please ?    There have been several proposals 
>>> in the past to fix this in    ssh_gssapi_acquire_cred  .  .  -       
>>> if (gethostname(lname, MAXHOSTNAMELEN))  -               return (-1);  
>>> +        lname = get_local_hostname(packet_get_connection_in()); 
>> 
>> 
>> Won't that break Kerberos authenticaton for sshd in inetd mode?
>
>
>It might break more then that. This change would appear to get the name of
>the interface, rather then the name of the host. It would then require the
>Kerberos to have a principal for each interface, and the client to know
>the name of the interface. The Kerberos client is trying to authenticate
>to the host, not an interface.
>
>But if the host actually has multiple names, a possible change is to
>pass GSS_C_NO_NAME rather then ctx->name to gss_acquire_cred. This then
>leaves it upto the GSS to determine the acceptable names. In the Kerberos
>case this would be any principal name that is in the keytab.
>
>  RFC2743 says:
>   o  desired_name INTERNAL NAME, -- NULL requests locally-determined
>    -- default
>
>If you add this change, it should be a configuration option, as
>the Kerberos replay cache may not be used, and there might be other
>principals in the keytab that are not expected to be used by sshd.
>
>The sysadmin can also set the KRB5_KTNAME env to point to a specific
>keytab before starting sshd if there are any special situations.
>
>
>> 
>
>-- 
>
>  Douglas E. Engert  DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444