ecryptsfs and ssh don’t play nice together

I encountered the most aggravating issue today. My zeal for security combined with my lack of understanding was my downfall.

Recently I bootstrapped a server with a fresh Ubuntu installation. When asked if I wanted to encrypt my home directory, I didn’t hesitate for a second. No baddie was pulling my files off my disk, no hell no.

When ungodly winds struck LA last weekend, the power went out. Nine times out of ten, any wind over 15mph and LA’s grid is struggling.

So I turn this machine on again, and go to SSH in. It prompts me for my password.

Strange, I absolutely had my public key installed on the server.

I ran ssh-copy-id again for good measure.

Same problem.

I scoured Google with vague terms “SSH public key still prompts for password send help”

And then it worked! I ran ssh and it logged me in smoothly, no-hassle, as God intended.

Did I fix it? Take Note: When something works without any change to the system, no you did not fix it. I’m looking my fellow programmers dead in the eyes right now.

I carried on, logged out and tried again. Once again prompted for the password.

OH I logged out of all my sessions! I could only SSH with public key authentication when I was already logged in with a separate session.

What the devil is this bullshit … ecryptfs … my home directory was only decrypted and mounted when I had an active login session.

Where do SSH keys live by default? /home/user/.ssh/authorized_keys.

 

SSL for Everything Else

Last post I mentioned how easy it was to setup SSL with AWS Certificate Manager.

But what about all your other servers? Are we going to cough up $16 per year for a single-domain SSL certificate from Gandi?

Negatory.

Let’s talk about Let’s Encrypt. I downloaded their Linux version and got down to business.

Here is a running tally of my steps.

  1. Google “nginx letsencrypt” and find this DigitalOcean guide.
  2. Stop my nginx server to free up port 80, which is used in the letsencrypt process.
  3. run $ ./letsencrypt-auto certonly –standalone
  4. Enter my domain name.
  5. Make 15 seconds worth of changes to my server blocks in nginx.
    1. Redirect port 80 -> 443
    2. Setup a block for port 443 SSL, all in the guide
  6. $ sudo service nginx start

It took 5 minutes to fully setup.

I love it when life is stupid easy.

Silly Security

No one gives a shit about my servers. They host a few funny sites and services mostly for personal consumption.

But recently I made the mistake of reading the details of the security update offered for my Mac.

So I set off to secure my shit once!

High Level Strategy:

  1. No more password authentication on my front-facing servers, ssh key auth only from a single control server.
  2. Design a hardened login scheme for the central control server.

Central Server Login Scheme:

Normal Setup

  • Create “intendeduser”, my user for personal, everyday activity.
  • Add “intendeduser” to sudoers
  • Install fail2ban, which mitigates brute force attacks to some extent.
  • Disable root login

Tiered Users

I made a duplicate of the nobody user, somebody:

$ useradd somebody -d /nonexistent -s /bin/sh

The somebody user would have no privileges, and would simply serve as the first stage in a 2-stage auth scheme. Remotely, you could ssh in as “somebody”, but no other user. A second ssh intendeduser@localhost would be required to complete the login as the intended user.

This was accomplished by adding the following to my /etc/ssh/sshd_config file:

AllowUsers somebody intendeduser@localhost

This allows “somebody” to ssh in from anywhere, but only allows us to ssh in as “intendeduser” locally.

Note: I wonder if localhost doesn’t actually guarantee local access only. I’ll investigate more later.

Issues

The “somebody” user still has a significant amount of access. He/she can browse and read the majority of the files on the machine. Guessing the “intendeduser” would be pretty trivial.

In my next post, I’ll discuss a solution using a chroot jail!

Possible Improvements:

Quick list of things that came to mind

  • Two-Factor authentication using a PAM (Pluggable authentication module)
  • Switch ssh port (I didn’t just for convenience)
  • Limited login time before “somebody” user is automatically logged out