Pending OpenSSH release, call for testing.

[Douglas E. Engert]

Markus Moeller wrote:
> Douglas,
> 
> OK, you are right it can work, but I am wondering if you say for your rlogin you
> have to use the real hostname which I think means you connect always to one
> interface, the one the hostname is assigned to, you can't use the others. 

No, what I meant was the rlogin did not use GSSAPI, but calls Kerberos directly,
and can connect to the rlogind using multiple identies, as long as the keytab
had a matching principal, thus showing that this was not a Kerberos limitation.

If you
> look at other daemons (e.g. ftpd) you'll find:
> 
>                 /*
>                  * Need to get the hostname of the interface the client has bound to
>                  * (on fd 0) so that we can get the correct keytable entry
>                  */
> 
>                 address_len = sizeof(bound_addr);
>                 if (getsockname(0, (struct sockaddr *)&bound_addr, &address_len)
> != 0) {
>                         reply(501, "couldn't get locally bound socket name
> (%d)\n", errno);
>                         syslog(LOG_ERR, "couldn't get locally bound socket name
> (%d)\n", errno);
>                         return 0;
>                 } 
>                 if (!(hp = gethostbyaddr((void *)&bound_addr.sin_addr,
> sizeof(bound_addr.sin_addr), AF_INET))) {
>                         reply(501, "couldn't canonicalize local hostname\n");
>                         syslog(LOG_ERR, "Couldn't canonicalize local hostname");
>                         return 0;
>                 }
>  
>                 if (debug) 
>                         syslog(LOG_INFO, "Using interface %s\n", hp->h_name);
>  
>                 strncpy(localname, hp->h_name, sizeof(localname) - 1);
>                 localname[sizeof(localname) - 1] = '\0';
> 
> 
> This works for inetd started ftpd or as daemon process. Normally (from my
> experience) the selection of the principal by the client is given by the service
> and the hostname the client wants to connect to (this is also true for ssh).  The
> server has to determine the principal from the connection IP-address not the
> hostname to be in sync with the client selected principal.

The other way to look at this is the client selects the principal. The server will
accept this as long as there is a matching principal in the keytab. So the server
does not even need to determine its name from the connection. This is what
GSS_C_NO_MANE would be doing. The admin adds then  the needed principals to the
keytab. This also means that the admin needs to make sure there are no unexpected
principals in the keytab.


  It won't break
> anything in my opinion. I think a configuration option which selects either
> GSS_C_NO_NAME or the connection IP-address would be the best.

Sounds good, but how about a third option to use the hostname as does now?

> 
> Regards
> Markus
> 
> 
> 
> On Mon Sep 13 21:11 , 'Douglas E. Engert' <deengert at anl.gov> sent:
> 
> 
>>
>>Markus Moeller wrote:
>>
>>>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.  
>>
>>Not true. For years we have had Kerberized hosts with multiple addresses.
>>Kerberos is authenticating principals to each other. The client/user gets
>>a ticket for host principal, using the name it expects the host to have
>>a principal for in its keytab.
>>
>>The situation in question is similar in that one host is pretending to be
>>multiple hosts, which may or may not use the same interface.
>>
>>Its not a Kerberos limitation. Its an application requested restriction, as
>>the gss_acquire_cred(... desired_name,...) is specifying the name of the
>>single service principal it is to accept.
>>
>>If this was GSS_C_NO_NAME, then the underlying Kerberos can accept using any of
>>the service principals in the keytab.
>>
>>We have a number of hosts with multiple names, and one can use the kerberized
>>rlogin to login with either name, or ssh if the user uses the real hostname.
>>Since only the admins are logging in, we have not modified sshd to pass in
>>GSS_C_NO_NAME, but could use this if this was a modification.
>>
>>
>>
>>>
>>>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
>>>
>>>
>>>
>>>
>>>
>>-- 
>>
>> Douglas E. Engert  DEEngert at anl.gov>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois  60439
>> (630) 252-5444
> 
> 
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444