openssh unix dev - Feb 2003 - Connections over private network, Simon's GSSAPI patch

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

Stop shooting yourself in the foot. Run 2 sshd instances, one on the public 
interface, one on the private interface, and make sure they know their 
correct host names.

The only other sane option I can think of is to add an option to ssh and/or 
sshd that lets you select which client and/or server kerberos principal(s) 
to use explicitly, instead of automagically determining them. And that's a 
lot more work. And belongs in the GSSAPI code. Something like:

ssh -oClientPrincipal=carson.admin at taltos.org 
-oServerPrincipal=host/server.private at taltos.org server.private.taltos.org

or (in sshd.conf):
ServerPrincipal=host/server.private at taltos.org

If your're feeling really studly, have the sshd option take a list of 
principals.

-- 
Carson