A: "I just set up a cloud instance by running some shell commands by hand."

B: "You shouldn't do that, because of X and Y and Z. You should learn Puppet or Chef."

A: "Wait... did you just tell me to go spend thirty hours banging my head against solid objects, in exchange for nebulous benefits that I can't even perceive yet?"

B: "Why, yes, I believe I did!"

Ansible feels much less embarrassing to advocate.

Look, I can maintain my own ansible configurations (inventories, playbooks and roles), and the other groups need not be the wiser. They don't need to worry that servers are going to be reconfigured out from under them, since I am running my configurations explicitly. All they see is that I ssh'd in and did a bunch of stuff really fast. To work with my other groupmates, we just keep the files in git (just flatfiles, yes: just flatfiles). With git I have an audit log of everything that has changed (hosts that have moved environments, configurations that have been updated, etc). And like git it is as distributed as you want it to be. Want to run it from a central server only? Fine. Want to have your admins all run it from their workstations? Fine. Go for it.

Even if the server is ancient or weird (ie. no python), I can still manage it with the raw module.

Ansible gives me everything I want, with no fuss. It is so basic that I can do things the way I want to.

Personally I've found dealing with Ruby and the various versions rather irritating. I kind of wish I had started with Salt or Ansible because I know far more Python, than I do Ruby. I started down this bunny trail before Vagrant support Ansible and/or Salt. I guess it's not to late to start over... hahaha Maybe I will after the initial release.

I guess the only advantage of Puppet was that I'm able to do most of what I want using major modules...

Also, Ansible does not require you to mess around with dependency lists to ensure that packages/files are installed in the right order - the order is built into the yaml config file. You don't lose any capability, you just gain (and this is my personal opinion) ease of understanding the order that operations will occur in.

    This library does not protect against timing attacks. 
    Do not allow attackers to measure how long it takes you 
    to generate a keypair or sign a message. This library
    depends upon a strong source of random numbers. Do not
    use it on a system where os.urandom() is weak.

[1] - https://github.com/paramiko/paramiko/pull/152

[2] - https://github.com/warner/python-ecdsa

So, don't use it in the cloud? [1]

1. http://harvey.binghamton.edu/~ychen/chen-kerrigan.pdf

The other big win for me is I can read their code, I understand python & have a number of items I'll be able to contribute to upstream that will help others use the product.

(Then again, that's how it usually goes anyway.)

http://www.zeromq.org/area:faq#toc8

I've tried B, C, D, and E, and I like E.

And if you criticize me, I down-vote you. Classy.

There are ways to configure salt with masterless or behind vpcs or with syndics that are perhaps an enhanced security model. But defaults are for regular use cases, and for most cases the defaults are fine.

I suggest checking it out.

Why are you exposing VPN ports in public anyhow? Put them behind a VPN.

Seriously though, there isn't anything to say a VPN is any more secure than SSH.

There is a longer conversation that can be had to explain this. There are lots of mistakes one can make in managing a box with SSH that will easily lead to an account compromise, not even considering universal methods like 0-days, stack attacks, mitm, phishing, etc. The simplest defense to all these problems is a hardened VPN device on a separate network segment with separate authentication and strictly defined ACLs.

If you just run a personal VPS, I wouldn't worry about it. But if you ever start handling customer data, get serious about security and don't run SSH in the open.

Something concrete please..

SSH contains many features which may make it vulnerable to attack. If configured incorrectly it will expose the machine, and depending on the machine this could expose a big portion of your network. I could write 5 pages on abusing SSH options for entry.

After SSH itself, there's the operating system. PAM has had holes for years and yet people everywhere rely on it for their authentication. Their OS might not be patched up, and probably has had no hardening of the kernel or userland against typical attacks.

The box is also probably on a shared network segment, meaning your attack surface is now a whole lot bigger: many machines and user sessions to hijack.

On the other hand, a VPN on a separate network segment provides protection for all these components, if you do it right. Usually the VPN should be an appliance of some kind, with service by a company who spends its time hardening the device and patching the software regularly. This makes sure the configuration of the software is correct, the system itself is resistant to attack, and authentication/authorization is managed outside the machine, which means limited access to the network for specific user sessions.

You cut the attack surface down by separating their network access away from a specific network and shared server. You also cut down on mistakes in managing said service because everything is a managed service, not a config file edited by one or more admins.

Also consider that SSH just doesn't have the features of a standard VPN that make it useful on a network level. Its tunneling feature is a joke; using ppp is the closest way to provide an actual remote vpn tunnel. Persistent connections are nonexistent. Network access control is nonexistent. Pushing routing, DNS and other network information is nonexistent. It is not meant to be a network-level tunnel, it's a single-session user tunnel for remote hosts, not networks. The extra options and features for more network access are hacks.

If you wanted to emulate a VPN using SSH, you could:

  * put a machine on a separate network segment
  * apply Grsec and other patches
  * harden the filesystem and stop all services other than SSH
  * disable user logins
  * disable all features of ssh
  * enable all strict ciphers, modes, options for ssh
  * add ssh config options to run pppd as soon as the user logs in
  * configure PAM to use RADIUS or SQL to auth with a remote database
  * use iptables and some kind of packet-marking module to track network sessions by user id
  * create a custom application that configures iptables rules per user
  * constantly update all patches

SSH is not a VPN, and a VPN is not SSH. Like I said before, if you're just remoting into your personal box, I don't think you'll have issues, because nobody would care to break in. Bigger networks are a different matter.

Now, it seems like you're saying that vpn is more secure because it's often separated and more hardened. I guess that kind of makes sense, but isn't that really an argument for a single, hardened entry-point into the network? Could be anything.. And of course, this has its drawbacks as well =|

If you have a building you want to secure, you could make a lobby with a man-trap and a guard at the front desk and security keys for the lobby and on each floor. Or you could put a padlock on the back door. You decide whether it's worth the risk.

In terms of what to use to remote into your private VPS, just use SSH. A VPN would be overkill.

For many people ssh is considered secure enough. And any secure issues get immediate attention so you can be updated pretty quickly.

Now any software could have unpublished zero days, which is why I also do some other host based security.

You don't need to do this. SSH is secure enough. Require key-based authentication and leave SSH on port 22.

Sure, those drive-by attacks are pretty weak and not much of a threat against a hardened configuration and the real attackers will find the new port anyway, but it reduces noise significantly.

Cleaner logs are easier to parse, so the net result is that you can spot attacks that you care about much more easily.

1: at which point you'd most likely need to be a lot more involved anyways, and you should most likely be running something more serious in front of your server anyways...