0

I am starting a web hosting company and there are a few details that I have yet to figure out, one of them being some sort of SSH VPN to connect to our servers running CentOS 6 with cPanel.

So this is what I am looking to do...

1) Have a master server with specific user logins (user1, user2, etc.) for my employees. In order to SSH into any of our servers, they would all need to login to this master server first.

2) From this master server, they will be able to ssh server.example.com and the master server would be able to log them right in as root.

What I know needs to be done is generating a key pair for each user and putting their private key in the /root/.ssh/authorized_keys file on each server. I already have means to update this file automatically for each server using cron.

I can get all of that to work, but sometimes the login gets a bit screwy and I also have a problem with the connection timing out after about 15 minutes. I believe I have an idea to fix that, but any help would be appreciated.

Now, for the main question here, I want to be able to have users login using a short hostname or the prefix of the hostname instead of having to type out the entire thing when logging into a server. So if I have a server with the hostname s1.server.example.com, they will be able to use s s1.server (s will be aliased to ssh) for a quick login. I'm not positive how to do this, but if there is an easy way without needing to setup each and every server on the master server to have it's short name point to the full hostname, it would be a lot easier to maintain in the future. I'm guessing that some type of script could be written to check for the correct hostname that goes to the prefix would be needed.

Any bit of direction would be greatly appreciated here, I have tried so many different solutions without avail and would rather is work correctly without a whole bunch of "hacks" like I have been doing. Thank you!

EDIT

I wanted to update everyone here as I think I was pretty unclear. This system is only accessible by higher-level employees within the company in order to provide a quick and easy way to manage our cloud systems via root. Customers will not have access to these systems and any customers who may have root with their services, with be using direct root access.

Kyle Ross
  • 103
  • 4
  • 4
    Why in the world do you want them signing in as root? That's pure folly. They each need their own account(s), and should be using sudo for any root-level commands they need to execute. – EEAA Apr 17 '12 at 19:52
  • logging in as root is bad m'kay? – Lucas Kauffman Apr 17 '12 at 19:57
  • 2
    #1 Key to Success in Business: Do what you know how to do, leave the rest to other people. – Chris S Apr 17 '12 at 20:00
  • There are a lot of consultants on this site. Consultants that can help you avoid a customer crisis. HINT. – Wesley Apr 17 '12 at 20:03
  • In regards to root access, this system is only for higher level employees that need access to the servers via root. – Kyle Ross Apr 17 '12 at 22:33
  • @BigRossLabs - my comment still stands. As a best practice, **no one** should be accessing these systems as root - even your "higher level employees". Your senior sysadmins should lead by example in using sudo. Signing in directly to root directly is lazy, risky, un-auditable, and in general just a really bad idea. – EEAA Apr 17 '12 at 22:49

2 Answers2

2

If you have DNS setup properly, you should be able to use the short names. Putting something such as:

search example.com

in your resolve.conf will help with the name resolution. For updating the configs, ssh keys etc, you really need to look into something like Puppet or Chef. It will make your life a LOT easier down the road as your grow your web farm.

usrlocal
  • 66
  • 2
1

I'm going to recommend some different practices for you, in order to increase your security and give you some business differentiation with low-cost providers. As web hosting can be a low margin business, some differentiation with value-added services can substantially help with tighter margins, while increasing your lock-in.

Consider replacing standard SSH logins with:

  • IPSEC tunnels to a perimeter device, SSH to individual hosts
  • SSH tunnels using a PKI based on a hardware device (these you can sell*).

(or both together)

Wham, you are instantly a Security conscious web host :)

Logging in as root is considered a bad practice! Instead, have them log in as untrusted users, then use sudo to run commands that need root-level privileges.

Consider hardening all your centos hosts using a security hardening guide such as the NSA SRGs, CIS, or DISA STIGs, including the Apache guidance too.

If sticking with ssh in software, have the clients do key generation on their local computers as it is considered more safe. Give them an option to encrypt their private key, and upload it to you for escrow though, as a backup.

Quick refresh on PKI, such as SSH.

Public key = encryptor, no confidentiality requirements

Private key = decryptor, protect this, don't share it!

SSH private keys shouldn't be stored on remote hosts unless strongly encrypted

To SSH into hosts on the internet, you only need include the public key into the authorized keys file. See http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html

You can use alias and other commands in order to shorten details that a user may need to type in.

However, judging from the sound of your experience level, I recommend a little more practice before heading into Linux hosting. Trust is paramount!

  • Read up on Redhat's Certificate Management System, Certificate Authority software and potentially Dogtag
EEAA
  • 108,414
  • 18
  • 172
  • 242
Brennan
  • 1,388
  • 6
  • 18
  • No, they shouldn't use `su`. They should use sudo. – EEAA Apr 17 '12 at 20:30
  • Security should be easy, not hard. Running both SSH and IPsec just makes it harder for the user and exposes much more code to the internet. Besides, those hosts are already running PHP and the attacker may freely choose his point of attack. PHP and related applications are much easier to attack than a modern sshd is. – Alex Holst Apr 17 '12 at 21:05
  • An IPSEC tunnel in above mode that I mentioned can actually transparent when done in conjunction with a network device, and easier than SSH. I did not describe how to perform the implementation hardware for said rollout. Code is not exposed to the internet via running two tunnels, because successful authentication has to take place via tunnel 1 prior to access to tunnel 2. – Brennan Apr 17 '12 at 21:11
  • OK, I just went ahead and fixed that su thing. – EEAA Apr 17 '12 at 22:08
  • I agree with you here and excellent write up! Although I was a bit unclear in my original post. I have made an edit to further clarify. – Kyle Ross Apr 17 '12 at 22:41