Connections over private network, Simon's GSSAPI patch

[Adam Oline]

I'm sending this to both Simon and openssh-unix-dev because although the 
problem I'm having actually occurs in Simon's patch, it could be 
resolved with a change in the main code.

We are using openssh-3.4p1 plus Simon's GSSAPI patch to support Kerberos 
V5 ticket forwarding over ssh protocol 2.  We are using OpenAFS for user 
home directory space, and LDAP for user information, including home 
directory and password.  libpam-openafs-session is used to get an AFS 
token from the forwarded Krb5 TGT after logging into a machine using 
openssh+patch.

Everything is working fine when we ssh between two machines over a 
public IP connection.  No passwords are needed, krb5 tickets are 
forwarded using either the external-keyx or gssapi authentication 
methods, and afs tokens are retrieved.  The problem occurs when ssh'ing 
over the private network connection between two machines.

We have a number of two-node clusters where each node has a public IP 
address, as well as any number of private IP addresses, one for each 
additional network interface.  The additional network interfaces are 
connected back-to-back, and are used for benchmarking purposes, e.g. 
seeing how well two gigabit ethernet cards perform back-to-back in the 
same machine.  These benchmarks may be done using raw tcp connections, 
or using a message passing library such as MPI.  Some of the MPI 
libraries we use, including LAM and MP_Lite (implements a subset of the 
MPI specification), require the use of ssh as a means of connecting to a 
remote node and starting the user's executable.

Ok, so now I'll finally describe the problem.

If I do 'ssh <private ip of remote node>', the external-keyx and gssapi 
auth-methods fail, and I end up having to do password authentication, 
which is a pain.  The external-keyx and gssapi methods essentially fail 
because the server is expecting kerberos credentials for the principal 
"host/<public FQDN>@<REALM>", but the client is trying to provide 
credentials for "host/<private FQDN>@<REALM>".  Note that we were able 
to set up distinct kerberos entries for the private ip addresses by 
adding entries in /etc/hosts to resolve <private ip address> to <machine 
name>.<lo1>.<domain>, and using the same "private" FQDN in the kerberos 
database.

In order to get a kerberos entry for private IP addresses to work with 
openssh and Simon's patch, however, we would need to modify Simon's 
patch to try matching kerberos credentials against all of the kerberos 
host principals available for the machine, instead of just against the 
kerberos host principal for the public IP/domain name.  This is 
certainly possible, I think, but our sysadmin has pointed out that it 
would be simpler on our end to only maintain one kerberos entry per 
machine, instead of 3 or 4, depending on how many additional interfaces 
we're testing at once.

A somewhat simpler solution is a modification to the openssh code. 
Prior to doing key exchange and user authentication in ssh_login(), a 
check could be performed to determine whether the destination hostname 
corresponds to a public or private IP address.  If private IP, then 
change it to the hostname corresponding to the public IP.  Now the 
client code will use kerberos credentials for the public IP/domain name, 
and everything runs smoothly.

My main concerns here are the security considerations, and whether this 
might break something, e.g. would the user ever *really* need to connect 
using a private IP/hostname for the destination rather than the public 
IP/hostname?  I believe the network traffic is still actually going over 
the private link.

On the other hand, the change to hostname could be made deeper inside, 
specifically in Simon's patch, by passing the modified hostname only to 
the kerberos code used to build the credentials that are passed to the 
ssh daemon.  In that case, the main concerns are directed to Simon.  I'm 
not sure whether this compromises the security from a Kerberos 
perspective.  It seems to me that a host key is used to identify the 
*host*, or machine, and even though we're connecting through a different 
network interface, we're still connecting to the same machine.

I apologize for my long-windedness.  I hope I explained things clearly. 
  I would appreciate feedback from anyone, especially if this topic has 
come up before and I've missed it.  I tried googling for some relevant 
information but couldn't find any.

I will gladly develop a patch to either the openssh code or 
openssh+Simon's patch if this seems like a reasonable thing to do.


Adam

-- 
Adam Oline
Research Helper
SCL, Ames Laboratory
515-231-0242
adoline at scl.ameslab.gov