Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am thinking of colocating a SuperMicro 1022G-URF (16-way 1u server, 16 GB RAM) at a "place that does server colocation. I am running CentOS 6. The server will be a web server and an email server (and DNS, if I can't find a way to outsource the DNS to a service). I want to be able to connect into this server from "the road." I have looked at a few scenarios. I have ruled out SSH'ing into the box. I find there are too many vulnerabilities in SSH and I want to use StrongSWAN. I will be running iptables on the box.

Is it insane to set up a single server like this? In other words...I get a dropoff from the server colocation company - that is it. I am used to being in an environment with routers and switches and firewalls - this "single server scenario" is new to me.

Does anybody know of a better way of connecting to this single server?

Anything you could think of to help would be appreciated!

share|improve this question
There are two many vulnerabilities in SSH, so you want to add another complex piece of software which has its own potential security problems? Seems a bit misguided to me... – voretaq7 Nov 16 '12 at 20:52
up vote 5 down vote accepted

Does anybody know of a better way of connecting to this single server?

Yeah. Use ssh. IPSEC or a single-point VPN would be total overkill in my opinion.

There are not many (in fact there are currently no known) vulnerabilities in a properly configured OpenSSH setup, and nearly everybody is using SSH (most of us OpenSSH), so it's had a pretty thorough and complete security audit.
On the rare occasion that potential bugs are found they're patched very quickly, and vendors typically get those patches to their users in a timely manner.

My recommendation for you is to set up SSH correctly:

  • Disable remote root login (PermitRootLogin No)
  • Disable the use of Passwords to log in (require Public Keys)
    • Set a good passphrase on your private key
  • Optionally: Run SSH on an alternate port (something other than 22)
  • Optionally: Use Fail2Ban or pam_af to blacklist persistent attackers

and ensure that you install patches when they come out.
This will give you a secure, stable, reliable way to connect to your system, and if something breaks it will be easy to troubleshoot.

share|improve this answer
You are correct! Why my brain didn't think of using keys only...I have no idea. Also - good idea - blacklisting! - Thanks! – jim_m_somewhere Nov 16 '12 at 21:19
@jim_m_somewhere Generally if you're only allowing logins using keys (and your keys are secure) blacklisting probably isn't necessary - that's why it's the last item on my list. My systems have anti brute-force measures in place because it is possible to authenticate using One-Time Passowrds (S/Key) as well as using SSH keys, and though the chance of someone brute-forcing the OTP pass phrases is extremely small I decided to err on the side of paranoia. – voretaq7 Nov 16 '12 at 21:22
In my book - paranoia is good! Thanks for the info! – jim_m_somewhere Nov 16 '12 at 23:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.