Note

Kerberos is a secure authentication protocol. Many ports are involved, making it difficult to setup firewalls: e.g. Configuring your firewall to work with Kerberos. Further down this section, someone is ssh tunneling by LVS forwarding ssh to the realservers which use kerberos for authentication. In this case kerberos is just a login protocol that has nothing to do with LVS. There should only be one kerberos (ticket) server in your realm. You shouldn't LVS kerberos servers. Kerberos is a login protocol. There's no more reason to LVS kerberos, than there is to LVS login. However you can have the client login to kerberos'ed realservers.

several people

I'd be interested to know if LVS can be used and setup for silent login(no password prompting, i.e. using ticket forwarding) using ssh and kerberos.

Ryan Leathers ryan (dot) leathers (at) globalknowledge (dot) com 07 Mar 2006

this is not a good idea.

The kerberos replication system only permits one active admin server, so there is no opportunity for load balancing of the admin function. You shouldn't try to fool it by using LVS. You'll likely screw up the replication.

What you should do instead is to list multiple Kerberos key distribution centers (KDC'si) in your krb5.conf. Take a look at that and notice the section under [realms]. All you need to do is list multiple kdc's like so:

[realms]
	EXAMPLE.COM = {
	default_domain = example.com
	admin_server = krbadmin
	kdc = kdcserver1
	kdc = kdcserver2
	kdc = kdcserver3
	}

So, there you have it. By specifying multiple KDC servers you will be getting the behavior you really want, in case you lose a server for a little while, things will just keep on chugin' in your network. Don't get me wrong - LVS is a great tool, but its not the answer to every problem of service redundancy.

Ryan Leathers ryan (dot) leathers (at) globalknowledge (dot) com 02 Mar 2006

If you kerberize your host - that is to say, you have stuff like your ssh client using kerberos-compatible versions, and your authentication happening against kerberos, then kerberos works something like this:

I sit down at my favorite Linux workstation and open a shell so I can ssh to some other host on my network. Assuming I have not done so recently, the host I'm trying to reach won't be able to verify me. Instead, both my local host and the target host will rely on an authentication server to generate a new encryption key and distribute it to both parties. This is the session key. A Kerberos ticket is used to distribute the session key which includes info about me / my host that will be used by the target host to verify my connection. When the server passes this back to me, I forward it on to the target host as part of my authentication request. So, the ticket will be encrypted in a server key, which is known only by the server and the target host. nifty huh?

The ticket-granting-ticket just extends this to make life a little easier. We assume that some period of time is an acceptable amount for ticket granting without requiring the user to type in a password every time a ticket is needed. In short, I authenticate myself once to the server, and it allows me to perform any number of permitted authentications during the allowed time period. The ports used are likely going to be 88 for the kdc and possibly 749 for the admin server.

Karen Shepelak shepelak (at) fnal (dot) gov 04 Feb 2005

We are trying to get kerberos to work with LVS. We're ssh tunnelling to the realservers in an LVS forwarding ssh. We can kerberos through the ssh tunnel when connecting directly to the realservers, but not when we ssh to VIP:ssh. We get the following errors.

[karen@neptune karen]$ ssh -l shepelak minos-lvs01 Last login: Fri Feb 4 16:34:23 2005 from linux-test.fnal.gov aklog: Couldn't get fnal.gov AFS tickets: aklog: unknown RPC error (-1765328346) while getting AFS tickets /usr/X11R6/bin/xauth: timeout in locking authority file /afs/fnal.gov/files/home/room3/shepelak/.Xauthority Terminal type is xterm There are no available articles. /bin/touch: creating `/afs/fnal.gov/files/home/room3/shepelak/.Info': Permission denied <minos09>

Horms

	Note
	Joe: multiport protocols are difficult to loadbalance under LVS

Francois JEANMOUGIN Francois (dot) JEANMOUGIN (at) indexmultimedia (dot) com 03/10/2006

Rmi is NOT a TCP protocol as is. It is a subprotocol that is similar to FTP. The two RMI ports are dealing a transaction on the standard RMI port, and then, there is a dynamic port negociation. There is no way to make RMI load balanced, as well as there is no way to make it go through a firewall...

If you look at google:RMI+Firewal, you will find relevant documents about port negociation and all the (bad) ways to handle this (bad) idea that is RMI.

Mr. CBoy cboy168 (at) gmail (dot) com 10 Mar 2006

Currently I am using LVS-Nat with 2 real JBoss servers. In my test environment I have 1 client that spawns hundreds of threads that will invoke methods through RMI. The flow is like this:

Client sends a request to the VIP for a naming proxy which will get forwarded to RS1. RS1 will then push down the naming proxy back to the client, but will be masquerated by the director. The client will ask for the stub on the remote object so that it can invoke methods and it will be returned. Now the client has the stub and can start to invoke methods, but here lies the problem. The stub came from RS1 and when the client calls a method on the stub, it gets load balanced to RS2 and becomes invalid. In a real world example, turning on persistance would remedy this however in a test environment, I'm limited by hardware. Is there anyway to get threads on the same client to talk to the same real server?

The client code is something simple like

MyObject obj = (MyObject) Naming.lookup("rmi://VIP/obj"); obj.callSomeMethod();

All the underlying connection details are handled by Sun's RMI so I'm unable to keep 1 connection for each thread myself, so my only guess is to figure out a way for LVS to handle it.