Pending OpenSSH release, call for testing.

[Markus Moeller]

Douglas,

OK three possible settings(hostname,connection IP,GSS_C_NO_NAME) are fine for me too.

Thanks and Regards
Markus

On Tue Sep 14 12:27 , 'Douglas E. Engert' <deengert at anl.gov> sent:

>
>
>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