I am trying to decide whether OTP (Wikid) or Ssh Keys would be practically more secure in the following scenarios :
Option 1 - Wikid OTP : 3 Servers @ Slicehost; shared private network over which radius auth traffic passes. Hosts firewalled accordingly so that only my servers can talk to radius server. Assuming the Xen host (slicehost) is not compromised and their private network is trustworthy no other guests should be able to tamper with my radius traffic providing a reasonably (as per cost) secure & flexible setup
Option 2 - Good 'ol Ssh keys : 3 servers @ slicehost; No shared private network between the servers. I create ssh keys protected by a strong password. Simple and effective, providing my laptop is not compromised.
What are the Pros / Cons with associated solutions ?
Option 2 is probably the better choice with your 3-server setup. If you had 10's or 100's of servers, it's probably worth your time setting up Radius auth at that point. SSH is simple, secure and effective. I'd spend some time and tighten the default SSH settings too. Some values I like to change:
And if you know the usernames that will be logging in:
SSH has tons of options. You can run
man 5 sshd_config
to see them all.Radius is complex to set up and time consuming to maintain. It also generally has points of failure. If you only have three servers, use good 'ol ssh keys for simplicity and reliability. When you're designing security systems, it is very important to be able to completely understand the implementation. Unlike Radius, SSH is well understood by most admins.
To give some of the positives of Radius, it's better than ssh keys in a larger environment with more users and admins where you want centrally-maintained authentication and authorization. You see quite a few posts here like "My admin is leaving, how do I keep him or her out of my systems?"; Radius is one solution to that makes answering that question easier.
That said, for the simple case you presented, SSH keys sounds like a fine solution. Disable other SSH authentication methods, don't store copies of the private keys on the remote servers, perhaps escrow or otherwise ensure you have backups of your private keys just in case the laptop you refer to has a failure.