SSH with Multiple Interfaces

[Edward Murrell]

Since I googled for this, and couldn't find anything, I thought I post
my results.

Essentially, you have to set the hostname to the external interface,
because otherwise anyone on the general internet will not ever see the
internal DNS name (assuming you're keeping your internal DNS off the
internet, a not uncommon practice).

Continuing on with the example I used below, DNS needs to be set  up the
following way:

foogazzi.example.com                  => 34.88.99.100
foogazzi.office.example.com        => 10.0.0.1
                                                       => 34.88.99.100
34.88.99.100                     => foogazzi.example.com
10.0.0.1                             => foogazzi.example.com

hostname (set with /etc/hostname):       foogazzi.example.com

Essentially, you're saying that everything points to the external name,
and when SSH does forward and back DNS checks, everything correctly
checks out, but still allowing the forward DNS from the internal LAN to
work properly.

I hope this helps someone in the future. :)

Regards
Edward Murrell

Edward Murrell wrote:
> Hi there,
>
> I've currently fighting issues with a couple of multi-homed hosts on my
> network here.
> I've read the FAQ on this subject, and I'm still not sure what to do.
>
> http://www.faqs.org/faqs/kerberos-faq/general/section-47.html
>
> The problem stems from the fact that our the host in question resides on
> both an internal (10.0.0.0/8) and external network (general internet),
> and has two host names associated with it;
>
> 34.88.99.100      foogazzi.example.com
> 10.0.0.1      foogazzi.office.example.com
>
> The office.example.com domain is obviously not generally accessible to
> the outside world. The principle application here is SSH, which will
> account for about 99% of the Kerberos enabled traffic. SSH appears to
> have some very large issues with multiple interfaces and SSH.
>
> If I set the DNS and Reverse DNS to correctly return the above values
> and add both host/principles to the key  as you would expect, and tell
> the server that it's hostname is foogazzi.example.com, I get some
> interesting results.
>
> Logging in from the outside works fine.
>
> Logging in from the internal LAN does the following;
>
>     edward at coughdrop:~$ ssh foogazzi.office.example.com
>     Disconnecting: Protocol error: didn't expect packet type 34
>
> Essentially, the server complains that the client has handed it the
> ticket for the wrong host, and has bailed out.
>
> The other option I've tried is to tell the RDNS for the internal IP to
> return the external name. Eg;
>     10.0.0.1 => foogazzi.example.com
>
> However, this gives me the following output;
>
>     edward at black ~ $ ssh foogazzi.office.example.com
>     Address 10.0.0.1 maps to foogazzi.example.com but this does not map
> back to the address - POSSIBLE BREAKIN ATTEMPT!
>     Password:
>
> D'oh.
>
> Any suggestions?
>
> Regards
> Edward Murrell
>
>
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>