My brief reading of the iOS guidelines [0] says this is not allowed:

> 2.25 Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store will be rejected

[0] https://developer.apple.com/app-store/review/guidelines/

Runit is the default system daemon for Phusion's baseimage-docker Ubuntu image[0]. I've used it in a basic manner and have been very happy with it.

For containers it hits a real sweet spot: lightweight and easy to use within a limited scope of processes.

[0] https://github.com/phusion/baseimage-docker

From time to time I think about university apart from academics. I went to a state school and left w/ around $15k in student loan debt, but made some of the best memories of my life.

Those are the kinds of experiences money can never buy you again. No sports car later in life will ever bring you that kind of fulfillment.

Some quick tips for securing SSH:

1. Disable password authentication altogether

2. Create and use keypairs

3. Add an "AllowUsers foo" line to /etc/ssh/sshd_config so that only your user is allowed to SSH

4. Install sshguard or fail2ban and set the ban limit to a week

There are other things you can do, but I find this to be the lowest hanging fruit for the best security.

I like to do "PermitRootLogin no" as well, but I guess it's not really necessary if one uses some of the other config you've given.

IIRC I think "PermitRootLogin no" is now the default on most distributions. Debian at least: https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root...

I was curious, so I checked different distros. Debian-based distros set `without-password`, and others use the default `no`.

  * Arch Linux (openssh-6.9p1-1): #PermitRootLogin no
  * CentOS 7 (openssh-server 6.6.1p1-12.el7_1): #PermitRootLogin yes
  * Debian 8.1 (openssh-server 1:6.7p1-5): PermitRootLogin without-password
  * Fedora 22 (openssh-server 6.9p1-2.fc22): #PermitRootLogin yes
  * openSUSE 13.2 (openssh 6.6p1-5.1.3): #PermitRootLogin yes
  * Ubuntu 14.04.2 (openssh-server 1:6.6p1-2ubuntu1): PermitRootLogin without-password
  * Ubuntu 15.04 (openssh-server 1:6.7p1-5ubuntu1): PermitRootLogin without-password

Thanks for checking, but I'm not sure you're correct. AFAICT setting the default to "no" is not due for official release until later this month[1]. Maybe some of the distros are patching the upstream default directly in their source (seems bad idea to me), but I at least checked the CentOS version you referenced and it appears to default to "yes" in the source (and the config excerpt you cited is commented out.)

I looked into OpenSSH's commit history ([2],[3],[4],[5]) and it looks like some waffling and/or release-process side-effects resulted in the man page in 6.9 saying the default is "no", but the actual code retaining "yes" (confirmed in the portable 6.9p1 tarball). I kind of hope I'm wrong somehow; this is a bit disturbing.

[1] http://www.openssh.com/txt/release-6.9 [2] https://github.com/openssh/openssh-portable/commit/88a7c598a... [3] https://github.com/openssh/openssh-portable/commit/d921082ed... [4] https://github.com/openssh/openssh-portable/commit/47aa7a0f8... [5] https://github.com/openssh/openssh-portable/commit/7de4b03a6...

Ah, you're right. I read sshd_config(5) on Arch, which uses 6.9p1 and says the incorrect default is "no". I assumed this was the case on other distros.

So to correct my previous post (I can't seem to edit?), it should be, "Debian-based distros set `without-password`, and others use the default `yes`."

Thanks for the correction!

Thanks for the reply. On editing, I'm not sure exactly how it works, but posts on HN become uneditable at some point.

I came across this post[1] and bug comment[2]. If I'm understanding correctly, Red Hat will not follow the OpenBSD upstream on this! So I would guess CentOS and Fedora will also keep allowing root login, with password, by default.

[1] https://lists.fedoraproject.org/pipermail/package-announce/2... [2] https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26

Just got set to the default on OpenBSD, so it should be shipped in 5.8.

The reason for this isn't security-related, if you've followed the steps above and have applied them to root. The reason to not allow root login is so that each of multiple administrators must login using their username and then become root or use sudo. That way if you look to see who did what, you get a username rather than "root did that". Which, of course, you usually need root to do things that end up being checked into.

I would say auditability is still security-related, but yes, this is good practice too. You should probably also make sure root has a locked password, so that things other than SSH won't allow root login.

> There are other things you can do, but I find this to be the lowest hanging fruit for the best security.

During the years I've found that changing the port to something like 7865 decreases login attempts up to 100%. Personally it's always the first thing I do along with changing LoginGraceTime to 5s

What actual benefits does changing the port offer?

Usually automated bulk (non-targeted) hacking tools don't like to spend time looking for services on non-standard ports. I get zero ssh hack attempts on my machines ever since I changed to a non-standard port vs 100s of attempts everyday previously on standard ssh port.

It stops your log from filling up with half-assed attempts to break in.

Here is a pretty good guide for configuring SSH in a secure way that also goes into detail regarding the crypto side: https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

You probably also want to set kex, ciphers and MAC preferences in your client config for when you connect to servers with suboptimal settings.

Personally, I have also moved away from RSA keys and prefer using Ed25519 ones instead.

I am curious as to why DenyHosts is not mentioned in this context (beside fail2ban and sshguard. Is its use deprecated?

I ask because I administer about 300 servers with DenyHost grandfathered on the servers. I've googled a bit to see the relative merits and DH is just for ssh whereas fail2ban is more general.

I somehow didn't know about sshguard - it looks interesting (and also seems to do more than just ssh brute force blocking).

So... do I need to take DH off the herd and replace?

I very much doubt Apple sells anything at a loss. It's really not their style. Their margins are the envy of the entire industry, and Apple takes home 90% of cell phone profits[0]

The fact that they can create a phone/device with "inferior" tech and sell it at blockbuster margins proves to me that most people aren't interested in specs, but rather the whole experience and ecosystem. This is something Apple understands well and invests heavily in experience.

[0] http://www.cnbc.com/2015/02/09/dominant-apple-takes-90-of-sm...

Some of us prefer this screen size. I'm actually holding off until the 6s to see if they launch a model with a small screen.

Oh absolutely, I can see that people still prefer that screen size, I'm just surprised that Apple decided not to go with a larger size on the iPod Touch.

I found iterm2 to be my most-missed piece of software when switching to linux desktop. Terminator just doesn't compare with ease-of-use, look, and feel. Gnome terminal is nice but lacks some of the rich features.

Why not just use AWS? Seems like you went from bad to slightly better.

There's no reason to fear virtualization, and the automation is definitely one of the best aspects of running in a major cloud.

Because I prefer a set of simple and basic tools used in combination to accomplish something instead of a "push this button and it does everything" approach. It's the *nix pipe mentality of combining simple well built tools to build solid and reliable things that you can adapt any way you please.

I also build things that are heavy on the network side, and virtualization drops networking performance a great deal (this may be changed these days, not sure).

Don't get me wrong. I don't fear virtualization. I use virtualbox and vmware heavily for development, and yes they do have a purpose, but it's a bad fit for the type of projects I build.

I just find that anything in life that just continues to add features for the sake of adding features, and create more and more "magic" push buttons to solve your problems eventually goes to crap and becomes a fragmented dependency hell that I would rather not deal with. And yes, I do love Golang.

What? AWS is great because it has a nice console but it also gives you direct access to all the VMs and there is a AWS command line you can install to program/script everything. What's missing here?

By your response, I can tell you haven't used AWS much. Using EC2 by itself is as simple as DO.

DO is much cheaper than AWS.

I think the H1B program is great when it works, and I've seen it function because I've worked with some amazing and talented workers from countries such as India, Spain, France, etc. I really felt like we nabbed the best people from those countries. For these engineers, the US should be stapling green cards to the backs of their pay checks.

The problem here is that this group of workers is clearly being hired only because they provide a steep discount to local talent. This has nothing to do with skill, and in fact usually the engineers who take these positions are low-skilled. Think about it, who else would take a steep pay cut, work unreasonable hours, and take on a supervisor who threatens deportation on them?

For every H1B we hire in this category we make it harder to bring and keep a skilled worker. They don't fit the mould of disposable and cheap labor, so they don't get sponsorship. They refuse to take a pay cut just because they're a foreigner, and rightly so.