[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] ssh'ing to Cluster IP aliases.

In the message dated: Thu, 24 Apr 2008 17:02:54 EDT,
The pithy ruminations from Lon Hohberger on 
<Re: [Linux-cluster] ssh'ing to Cluster IP aliases.> were:
=> On Thu, 2008-04-24 at 15:29 -0400, Lon Hohberger wrote:
=> > On Thu, 2008-04-24 at 15:23 -0400, Lon Hohberger wrote:
=> > 
=> > I'm writing step by step wiki article now. ;)
=> > 
=> > [Note: it will need to be expanded for non-Red Hat/Fedora distributions]
=> Here's how to do it so that each service has a different ssh key (which
=> can be different from the host's ssh keys):
=> http://sources.redhat.com/cluster/wiki/ClusterSSH

Impressive. Well documented. On the other hand, I really try had to avoid 
changing things like vendor-distributed /etc/init.d scripts. I feel that causes 
many problems in future maintenance and complicates troubleshooting.

=> This is designed to ensure that each {key, IP} pairing is static so that
=> connecting to a host (or a cluster IP) will not cause ssh to complain -
=> because each IP has a different SSH key.

I believe there's a much, much, much easier way of dealing with this.

Don't make any changes on the servers (ie., run a standard ssh 
config, which won't break everytime you run "yum update").

On the client, put in multiple host entries in the ~/.ssh/authorized_keys file,
as in:

	clusterVIP, node1 1024 35 12487479769271803949013278496...

this tells ssh that the given key is valid for all the named servers 
("clusterVIP" and "node1", in this case).

If you have different host keys for each server, you'll need multiple 
authorized_keys entries, each one naming the cluster VIP and the specific node, 
and specifying that node's key. Thus, the clusterVIP will have multiple valid 
keys, each one corresponding to a different node.

If you use the same host key for each node, you can list all the nodes as a 
single entry in the authorized_keys file, as in:
	clusterVIP, node1, node2, node3, nodeN 1025 35 8813746318910438843...

I haven't actually used this method with VIPs on RHCS clusters, but I have used 
it to connect to other clusters (BSD, Sun).


=> Comments welcome.
=> -- Lon

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]