Connections over private network, Simon's GSSAPI patch
adoline at scl.ameslab.gov
Tue Feb 4 10:02:42 EST 2003
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
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
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.
SCL, Ames Laboratory
adoline at scl.ameslab.gov
More information about the openssh-unix-dev