On Jul 1, 2005, at 12:55 PM, Beth Kirschner wrote:
>> Is there any chance that TCP/UDP ports could be opened only between
>> those machines? For cluster usage, this is relatively common.
>> Specifically, you have some measure of trust between your cluster
>> machines, but not anywhere else.
>
> Unfortunately these machines are not behind a firewall -- they are
> public access workstations that we use for cycle-scavenging in the
> off-hours. I'll see how the sysadmin feels about opening up just the
> high user ports on these servers. Can you point me at the code which
> handles the TCP/UDP socket communication, just in case?
It's been quite a while since I've looked into this part of the code,
but I'm pretty sure that it's all in share/etc/socket.c (our wrappers
around standard socket stuff). We actually need both TCP and UDP, so
you'll need to modify both of those functions that create server-side
sockets. If you also need to modify outgoing sockets, you'll need to
modify those subroutines as well.
It probably wouldn't be too hard to use SSI parameters for this kind of
stuff, or, if you just need to get it working, hard-code in the ranges.
Be sure to leave room in the range for *all* incoming and outgoing
sockets (e.g., the number of processes you expect to run in your
largest parallel job plus a few more). When opening server-side
sockets, don't forget to loop over the range until you get one that
works.
>> For node keys, it's easiest (and there are few negative security
>> implications) to initially setting up a list of known node keys to all
>> your nodes. Hence, every node knows the public key of every other
>> node.
> I was refering to node keys -- and the reason I asked is our very
> security concious sysadmin does not like the idea of having a list
> known node keys distributed to every other node. You mention this is
> the 'easiest' route -- what are the other options?
There are shades of grey in every situation. Here's my take on public
ssh keys:
There's really no reason *not* to distribute the public keys around to
all other nodes. They're *public* keys, after all. Anyone who
connects to the machine via ssh will be presented with the machine's
public key -- so it's not like you can hide them. Distributing them
around in a "known nodes" list (in the ssh installation on each node)
actually ensures that when you ssh from one machine to another, you
actually get the machine that you think you're getting to.
Specifically, if you get a different key than what is in the "known
nodes" list, ssh will present the user with a warning of a possible
"man in the middle" attack.
This is as opposed to each users caching each node's public key the
first time they connect to the remote node (try it -- you'll get a
prompt saying that this is an unknown node; the default action is to
cache the key under the user's $HOME/.ssh). With a centralized known
nodes file, at least the sysadmin has positive control over this, and
can be sure to update keys when necessary (as opposed to users having
to update their personal caches when/if keys change).
In short: there is nothing gained by trying to hide node public keys.
My $0.02. :-)
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
