Other than remote login, there's various useful things you can do with ssh, like running a remote command, multiplexing connections to save on server resource, setting up ssh aliases to save you some keystrokes, and so forth. 

Recently, when my partner logged on a recently created CentOS server hosted at Digital Ocean, he saw the following messages:

Clearly that wasn't us trying to log in. Obviously, there was some malicious user(s) likely trying to enter our server with brute-force attacks. We were under a ssh brute force attack. Such malicious scan is not uncommon these days. It came just a couple days after our new server was up.

I learned a few good ways to prevent this:

1. Change default SSH port, 
   
2. Only use SSH keys (and disable password authentication), and
   
3. Use fail2ban
   

In CQ, let's say we want to expose some sort of REST API for our internal clients, but don't want these API's accessible by the public. For example, say we'd like the said JSP to be available internally (inside firewall), and to be invoked via the web. The API's responsibility is to clear Dispatcher cache via curl command behind the scene.

Production CQ instances deserves tighter security policy. OOTB CQ is too loose in security. For example, you don't need to open your production for client software like CRXDE to access it, nor do you want to open up WebDAV if not necessary. Most importantly, the default password of the super user 'admin' have got to be changed, which is not a straightforward process as you'd expect. 

In this post, I outlined specific steps that I took to tighten up security of our CQ Author and Publish nodes in a production environment. If you are planning to launch a public facing CQ, you can go through the same checklist.