GSSAPI auth and NAT Problems

Tue Aug 7 10:12:03 EDT 2012

On 8/7/2012 5:23 AM, Mauricio Tavares wrote:
> On 08/01/2012 11:04 AM, Douglas E. Engert wrote:
>>
>>
>> On 8/1/2012 8:09 AM, "Jörg Herzinger" wrote:
>>> Hi, I am trying to get GSSAPI auth to work and the problem ist that my
>>> kerberos server and the ssh server I want to connect to are behind a nat.
>>> My setup looks like this:
>>>
>>> my_laptop -------- virtual_machine_host ----- kerberos & ssh server
>>> (any ip here)    128.131.XX.YY - 10.0.0.1     10.0.0.2 & 10.0.0.3
>>>
>>> Port forwads are done by iptables on my virtual-machine-host. Port 22 ist
>>> forwarded to my ssh server. I can get a kerberos ticket easily on my
>>> laptop:
>>> joerg at laptop ~ % kinit joerg
>>> Password for joerg at REAML.AT:
>>> joerg at laptop ~ % klist -af
>>> Ticket cache: FILE:/tmp/krb5cc_1000
>>> Default principal: joerg at REALM.AT
>>>
>>> Valid starting     Expires            Service principal
>>> 08/01/12 09:34:39  08/01/12 23:34:39  krbtgt/REALM.AT at REALM.AT
>>> 	renew until 08/02/12 09:35:00, Flags: FPRI
>>> 	Addresses: (none)
>>>
>>> Connecting to my virtual machine host with gssapi auth also works like
>>> expected but when I try to connect to my ssh server gssapi fails (No valid
>>> Key exchange context) and I am prompted for a password. Connecting via ssh
>>> from my kerberos server to my ssh server internally works too.
>>> The stange thing i found is that even with NO host keytab on my ssh server
>>> I do get a ticket when trying to connect.
>>>
>>> joerg at laptop ~ % kinit joerg
>>> Password for joerg at REALM.AT:
>>> joerg at laptop ~ % klist -af
>>> Ticket cache: FILE:/tmp/krb5cc_1000
>>> Default principal: joerg at REALM.AT
>>>
>>> Valid starting     Expires            Service principal
>>> 08/01/12 09:46:42  08/01/12 23:46:42  krbtgt/REALM.AT at REALM.AT
>>> 	renew until 08/02/12 09:47:03, Flags: FPRI
>>> 	Addresses: (none)
>>> joerg at blackmini ~ % ssh root at virtual-machine-host
>>> Warning: Permanently added 'virtual-machine-host,128.131.XX.YY' (ECDSA) to
>>> the list of known hosts.
>>> Password:
>>>
>>> 130 joerg at laptop ~ % klist -af
>>> Ticket cache: FILE:/tmp/krb5cc_1000
>>> Default principal: joerg at REALM.AT
>>>
>>> Valid starting     Expires            Service principal
>>> 08/01/12 09:46:42  08/01/12 23:46:42  krbtgt/REALM.AT at REALM.AT
>>> 	renew until 08/02/12 09:47:03, Flags: FPRI
>>> 	Addresses: (none)
>>> 08/01/12 09:46:57  08/01/12 23:46:42  host/virtual-machine-host@
>>> 	renew until 08/02/12 09:47:03, Flags: FPRT
>>> 	Addresses: (none)
>>> 08/01/12 09:46:57  08/01/12 23:46:42  host/virtual-machine-host at REALM.AT
>>> 	renew until 08/02/12 09:47:03, Flags: FPRT
>>> 	Addresses: (none)
>>>
>>
>>> I already read a lot about address less tickets and "rdns=no", but all
>>> this seems way outdated. The config option "extra_addresses" looks
>>> promising but I didn't have success with this either. I am working on
>>> ubuntu laptop 11.04 and ssh server is Debian Squeeze.
>>> Any ideas or further suggestions on what I could try to get this working?
>>> This would be quite important for me.
>>
>> The above ticket is only good for  services on virtual-machine-host.
>> But the service is on ssh-server
>>
>> Kerberos uses hostnames in tickets, not IP. So what is the host name
>> of your ssh-server at 10.0.0.3? Sounds like you already have a principal
>> for it in the KDC and a keytab.
>>
>> You will then need to tell your laptop, that the IP number for the
>> ssh-server is the same as the virtual-machine-host, so the ssh client
>> will get a ticket based on the name and ssh will make the TCP
>> connection to the IP and port to the virtual-machine-host that will
>> route to the ssh-server.
>> The both the client and ssh-server will be using the same name
>> for the prinbcipal.
>>
>> Running with ssh -v -v -v  and sshd -d -d -d
>> will give debug info.
>>
>> You may want to assign a forwarded ssh port for each of your
>> back end servers, and leave 22 for the virtual-machine-host.
>> You could then ssh to any of them from your laptop.
>>
>> Your laptop will then have to use a name and port for each.
>> The /etc/hosts file will have all the names mapping to the
>> IP of the virtual-machine-host.
>> ~.ssh/config could add the port.
>>
> 	Correct me if I am wrong but what you are saying is to put in
> /etc/hosts (using the OP's example)
>
> 128.131.XX.YY	kerberos.lan.com ssh.lan.com
>
> I tried that and when I did
>
> kinit -fAp
> ssh -vvv -p 1234 -o GSSAPITrustDNS=no ssh.lan.com
>
> ssh acted like it was trying to authenticate against kerberos.lan.com,
> not ssh.lan.com.

Looks like ssh is doing a revers lookup, so that will not work.

See if your ssh client supports GSSAPIServerIdentity, Ubuntu does.
http://comments.gmane.org/gmane.comp.encryption.kerberos.heimdal.general/5848

I have not tried it, but it looks like it is designed for port forwading.
The in your ~/.ssh/config:

# assuming virtual-machine-host port 2203 is NATed to 10.0.0.2 port 22 ssh.lan.com
	Hostname virtual-machine-host
	Port 2203
         GSSAPIServerIdentity ssh.lan.host

#assume virtual-machine-host port 2202 is NATed to 10.0.0.1 port 22 kerberos.lan.com
Host kerberos.lan.com
	Hostname virtual-machine-host
	Port 2202
	GSSAPIServerIdentity kerberos.lan.com

You can then forget the changes to /etc/hosts.

>
>>>
>>> thanks,
>>>        Jörg
>>>
>>>
>>> ________________________________________________
>>> Kerberos mailing list           Kerberos at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>>
>>>
>>
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

-- 

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