This question already has an answer here:


We have our own datacenter which houses platform specific environments and each environment is isolated. Eeach environment is also has 3 tiers (Web Servers, Application Servers & Datastore). We also plan on introducing an Automation framework(environment) which needs to communicate with the platform specific environments hosts.


private datacenter [Automation environment host runs commands ----> <ssh> ---> platform hosts]


Some team members have raised this as a security concern. Specially ssh access into the DB servers in tier 3. Now I'm more of a dev than an ops guy so I'd like to get more of a thorough explanation on why this might be too much of a risk.

Can someone clearly highlight why this is not recommended? or perhaps it is not a risk, and if so can you please highlight the considerations to implement it.


marked as duplicate by schroeder, Jens Erat, Eric G, Mark, M'vy Mar 18 '15 at 8:37

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • short answer: Having direct access to the server allows attackers to pound on the door and get in. There are ways to secure that access (for ssh), but in general, you want to seriously limit access to servers. – schroeder Mar 17 '15 at 23:12
  • If you've properly secured your SSH, it's more akin to letting attackers beat their heads against a brick wall. – Mark Mar 18 '15 at 8:03
  • @Mark A brick wall that may or may not have a hole in it somewhere – Redwolf Programs Dec 14 '18 at 16:03

Can someone clearly highlight why this is not recommended?

Because any running service is increasing your attack surface. Especially with network capable services, you're always exposed to danger. I don't think anyone can give you a more specific answer than that, since the SSH implementations tend to be quite OK from a security standpoint. Nevertheless there is always the possibility that an exploit is discovered, granting anyone sending the right packets to your server access or that you've greatly misconfigured your servers.

But, even if you assume that the software itself is flawless, there are a couple of reasons why you might want to re-think your approach. Obviously, you haven't told us and details about your setup, but in the real world key management, audit trails and firewalling is always an issue. Aiming for another approach might therefore be a good idea.

  • For this reason also, the firewall operates as a separate physical component from the application server. – munchkin Mar 18 '15 at 13:35

Ultimately you need remote access to your servers but there are some things you can do to keep the bad guys out.

Don't run the internet facing SSH on an IP used by the application. Ideally use a dedicated host acting as a jump box. Use port knocking. Use key pairs. Use fail2ban. Don't allow root logins. Restrict access to a named group. Don't use shared logins. Don't allow direct access below the presentation tier.

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