What I don't get is why their Chef server has to be publicly reachable at all.

Shouldn't it be available only through their internal, private network?

I might be missing something here.

The chef server is hosted alongside our production platform - due to various issues maintaining it in our physical offices isn't viable - so we need to be able to use 'knife' from locations that are considered 'public' to our production network. Plus we have remote workers (like me!) who need access to manage the infrastructure using chef.

It's not an ideal situation, but young and growing start-ups work with what we can get. At least the roof doesn't leak! (My last start-up employer was based out of a spare room in a heating company, and the roof leaked every time it rained - and in Edinburgh it rains a lot!)

I know what you're talking about, really.

My piece of advice: use OpenVPN for remote workers and even for connecting those "public" servers outside your production network.

It's really worth it.

It's something we considered, but grafting it into the existing set-up didn't seem like it was worth the time invested, whereas the chef work Ced did not only made us actually more secure (with SSL), it also ticked a box on our security audit.

We're making plans for the next stage of our production platform just now, and will revisit all this stuff then.

Nice step with the port troubleshooting!

Yeah, the debugging part is the most interesting - chance to introduce some nice tools like ngrep.

Am I the only one who came here thinking of a Southpark reference?