Hooray for encrypted home directories



  • One of my current side projects is to set up a Linux machine at home with SSH open to the Internet, so I can access home computers when I'm away. In the interest of security, I decided to use key-based SSH authentication instead of password-based, on the assumption that I will at some point get pounded by brute-force login attempts if port 22 is open to the world.

    So I got a VM created on my ESXi box, installed Ubuntu, and generated a key pair. The public key went on the Linux box, the private key went on my flash drive, and all was well. I disabled password authentication for SSH and connections without the private key were rejected.

    It worked great, until it didn't. The new Linux VM would intermittently tell me my private key was invalid. And as I kept hacking at config files, restarting the ssh service, and reading all the accepted StackOverflow answers that simply tell me to do what I already tried which didn't work, I eventually realized my key-based SSH login only worked if I was simultaneously logged in on the actual desktop!

    The SSH public key lives in /home/mott555/.ssh/authorized_keys. And when I installed Ubuntu, I'd selected the option to encrypt my home directory. The home directory can only be unencrypted by my user password, which is not provided when using a key-based login! If I was already logged in on the desktop, the home dir was unencrypted so the SSH server had access to the key and could work.

    I don't actually need home dir encryption, it was just one of the OS installer questions and I thought "Oh that looks cool, I'll click yes!" Some kind of warning that things won't work if you use encryption would have been appreciated.

    I decided to remove the encryption. Naturally, the guide I followed left the OS in a non-working state. At least it was a fresh VM with nothing on it. I rage-deleted it and decided I'd spend another half-hour to start from scratch again.

    TL;DR/TBV: The best ways to secure a Linux system are incompatible with each other, with no warning that they don't work together, and will force you to compromise on security options to get a usable system.



  • Cue Blakey telling you how much you deserve it in 3... 2... 1...


  • Discourse touched me in a no-no place



  • Well, all that can be resumed to:

    ecryptfs-mount-private

    Easy!


  • :belt_onion:

    I've been bitten by that exact issue before 😄

    But yeah, like @PJH posted (presumably, didn't click the link) you can do it with both, you just have to f**k around with sshd's config and tell it to look for public keys somewhere other than your home directory. Annoying, sure, but I have trouble thinking of a viable alternative, assuming you actually wish to encrypt your entire home directory. Unless you symlink .ssh somewhere? No idea.

    The lack of warning is slightly obnoxious though, as is the lack of any feedback that your encryption is breaking sshd's ability to check your identity...


  • Discourse touched me in a no-no place

    @sloosecannon said:

    you just have to f**k around with sshd's config and tell it to look for public keys somewhere other than your home directory.

    Basically, yes.



  • @PJH said:

    Oh - wait - this isn't Coding Help...

    Doing It Wrong™...

    obligatory rant about how if I wanted your help i'd have asked for it.



  • @mott555 said:

    TL;DR/TBV: The best ways to secure a Linux system are incompatible with each other, with no warning that they don't work together, and will force you to compromise on security options to get a usable system.

    Because what Ubuntu offers seems to be some FUSE hack cobbled together no one else uses (that alone should raise a red flag in your head), with abysmal transfer speeds at that. You want your data encrypted, use some sort of LUKS/cryptoloop.



  • @mott555 said:

    @PJH said:
    Oh - wait - this isn't Coding Help...

    Doing It Wrong™...

    obligatory rant about how if I wanted your help i'd have asked for it.

    Obligatory comparison to blakeyrat.


  • Discourse touched me in a no-no place

    @mott555 said:

    obligatory rant about how if I wanted your help i'd have asked for it.

    Obligatory, but pleasant, reply pointing out that if you didn't want help you shouldn't have posted to begin with, or you could - ya know - ignore the proffered help...


  • :belt_onion:

    @PJH said:

    @mott555 said:
    obligatory rant about how if I wanted your help i'd have asked for it.

    Obligatory, but pleasant, reply pointing out that if you didn't want help you shouldn't have posted to begin with, or you could - ya know - ignore the proffered help...

    Obligatory meta response about how this always happens followed by an attempt to hijack the topic, turning it into a political discussion.


  • Discourse touched me in a no-no place

    @svieira said:

    Obligatory meta response about how this always happens followed by an attempt to hijack the topic, turning it into a political discussion.

    Obligatory internal sigh, followed by :rolleyes:.



  • Obligatory macro aggression

    %macro sqr(a);
    a*a;
    %mend;

    written in SAS, only lang with macros I could remember off the top of my head



  • Obligatory micro aggression that is also a macro

    #define WIN32_LEAN_AND_MEAN
    


  • Obilgatory misspelling of the word "Obligatory".



  • @DCRoss said:

    Obilgatory

    South park if it were Cajuns.

    O bil, gator Y!?!?!



  • You... bastards?



  • @mott555 said:

    One of my current side projects is to set up a Linux machine at home with SSH open to the Internet, so I can access home computers when I'm away.

    Or just turn on Remote Desktop.

    @mott555 said:

    The SSH public key lives in /home/mott555/.ssh/authorized_keys. And when I installed Ubuntu, I'd selected the option to encrypt my home directory. The home directory can only be unencrypted by my user password, which is not provided when using a key-based login!

    Wow imagine if Windows had that bug with BitLocker.


  • FoxDev

    @blakeyrat said:

    Or just turn on Remote Desktop.

    and require 50x the bandwidth just to find a file and print it?

    no thank you!



  • @blakeyrat said:

    Or just turn on Remote Desktop.

    My only Windows system is a power hog and gets shut down when I'm gone. I'm mostly concerned with being able to remotely administer my Minecraft (and related) servers, which all run Linux.



  • @accalia said:

    and require 50x the bandwidth just to find a file and print it?

    Who cares?


  • FoxDev

    @blakeyrat said:

    Who cares?

    look, not all of us only connect to the internet through fiber connections. some of us actually have bandwidth restrictions.

    yes i could remote desktop home, but it would be laggy as shit, or i could SSH in and have a lagless experience, get my shit done and disconnect again. all in the time it would have taken me to start one freaking application over remote desktop.



  • @accalia said:

    yes i could remote desktop home, but it would be laggy as shit,

    Have you actually tried it?



  • Dammit! :hanzo:
    Still, I only have myself to blame. You take yourself offline for a few days to do some real, distraction free work. You can expect others to get in with the witty cutting comments first


  • FoxDev

    @blakeyrat said:

    Have you actually tried it?

    yes! yes i fucking well have!

    and logmein and teamviewer and gotomyfuckingpc!

    they're all laggy as shit thanks to the crap upload i have on my ADSL package at home!

    I wouldn';t have said it was fucking well laggy as shit if i hadn't actually tested it!



  • Someone's getting pretty vexed. Maybe even jimmy-ruffled.


  • BINNED

    @blakeyrat said:

    Who cares?

    Ben L does



  • @blakeyrat said:

    Someone's getting pretty vexed. Maybe even jimmy-ruffled.


  • FoxDev

    ooook potato chips......


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Maybe even jimmy-ruffled.

    Jimmies get rustled, Blakey, and feathers get ruffled.


  • area_pol

    If you are looking for remote desktop solutions, I recommend X2GO. Most standard remote desktop programs require that you already have a session running, but this one allows you to create a new session, just like SSH.


  • FoxDev

    or i could do it via SSH

    y'know what works and DOESN'T SAP ALL MY BANDWITCH AND THEN ASK FOR FUCKING MORE!



  • Definitely vexed.


  • area_pol

    Nothing wrong with SSH, but since the discussion is already started, i thought I would share this technology.

    It actually uses SSH for the connection and is a variant of X-server forwarding, similar to running SSH with -Y option, just lets you access the whole graphical environment.


  • Discourse touched me in a no-no place

    @accalia said:

    BANDWITCH

    hee hee hee


  • FoxDev

    now that you mention it....


  • Winner of the 2016 Presidential Election

    @blakeyrat said:

    Wow imagine if Windows had that bug with BitLocker.

    The Linux equivalent of BitLocker is LUKS. Which doesn't have the problem described my @mott555.


  • Winner of the 2016 Presidential Election

    @mott555 said:

    And when I installed Ubuntu, I'd selected the option to encrypt my home directory.

    Doing it wrong™

    @wft said:

    Because what Ubuntu offers seems to be some FUSE hack cobbled together no one else uses (that alone should raise a red flag in your head), with abysmal transfer speeds at that. You want your data encrypted, use some sort of LUKS/cryptoloop.

    QFT

    TL/DR: Ubuntu sucks.
    <I still use it, because laziness



  • Seems to me the biggest wtf is that your encrypted files are freely accessible just because you're logged in on a different terminal. Could Linux not manage it so that only the session that's actually authenticated has access to the decrypted data?



  • @wft said:

    You want your data encrypted, use some sort of LUKS/cryptoloop.

    Not only that, but LUKS supports multiple keys to unlock it, so in theory you could write a script that would use your SSH private key (on the client side) to derive something that could be fed into LUKS over SSH as an alternative key file to unlock your home directory automatically.

    As usual, the :wtf: is in distros that assume you only want to use them like a desktop.



  • @Buddy said:

    Seems to me the biggest wtf is that your encrypted files are freely accessible just because you're logged in on a different terminal. Could Linux not manage it so that only the session that's actually authenticated has access to the decrypted data?

    No. If you are an administrator (root) on a system... even a Windows system... you have access to everything. That follows from the simple fact that the administrator can load modules/drivers into the kernel and therefore access all memory or impersonate anyone on the system.

    Your basic filesystem permissions protect one user from another though, regardless of encryption. So unlocking your home directory when you log in isn't introducing a big risk that other users will now have access to your files, unless you mess up the filesystem permissions too.



  • @quijibo said:

    unless you mess up the filesystem permissions too.

    It's Ubuntu, so every users gonna be in wheel by default right?



  • @quijibo said:

    No. If you are an administrator (root) on a system... even a Windows system...

    Not necessarily. The ownership and permissions setup on Windows can prevent an admin from having acces to directories and files. Now, as an admin, you can take ownership to get access, but that's really a workaround.


  • Java Dev

    I also believe that, at least on windows, encrypted files are protected with the account password. If you didn't use the password to get in (or the password got reset) the file data is not accessible.



  • "TL;DR/TBV: The best ways to secure a Linux system are incompatible with each other, with no warning that they don't work together, and will force you to compromise on security options to get a usable system."

    Not only are these not the "best ways to secure a Linux system", they're not even particularly good ways.

    Encrypted homedirs are a stupid idea. Don't use them.

    SSH keys are a good idea. Use them if you need to, but don't think for a second they'll do anything to stop some Israeli twat pounding away at port 22 with random usernames and passwords. The best way to stop that is to use fail2ban.


  • :belt_onion:

    @gordonjcp said:

    SSH keys are a good idea. Use them if you need to, but don't think for a second they'll do anything to stop some Israeli twat pounding away at port 22 with random usernames and passwords.

    Accepting only SSH keys won't stop them, but they sure as hell won't get anywhere...



  • My SSH server:

    • is running on a nonstandard port (because MilwaukeePC)
    • has password authentication disabled
    • has root logins disabled
    • has a different key pair for each device I connect to it from


  • @abarker said:

    Not necessarily. The ownership and permissions setup on Windows can prevent an admin from having acces to directories and files. Now, as an admin, you can take ownership to get access, but that's really a workaround.

    Work-around or not, you can still get to the files. So you need to trust all of the admins on the machine.

    What I was referring to was injecting code into the kernel to act as another user, so you wouldn't even need to change the filesystem permissions and so the target user might not notice that you had access to your files. That is worse than taking ownership as then they would know that you changed something.



  • @PleegWat said:

    I also believe that, at least on windows, encrypted files are protected with the account password. If you didn't use the password to get in (or the password got reset) the file data is not accessible.

    That's true, but here is the problem... Windows has an encrypted key store. In theory, if Windows can decrypt the key (say as you log in using your password), then a malicious module that runs as part of the Windows kernel code can also access that key and decrypt your files too. Yes it has to wait until you log in next time to use your password to get the key (but only once!), but after it has your key then all bets are off. Again, an administrator can load a driver, so any administrator should be assumed to have access to your key for as long as you are logged into the system (if not permanently).

    The only mechanism that should be safe is a removable hardware module (like a smart card) that never shares its private key with software, and does the decryption directly. This way no part of software knows your key, and therefore no one can copy it without having your hardware device.



  • @mott555 said:

    One of my current side projects is to set up a Linux machine at home with SSH open to the Internet, so I can access home computers when I'm away. In the interest of security, I decided to use key-based SSH authentication instead of password-based, on the assumption that I will at some point get pounded by brute-force login attempts if port 22 is open to the world.

    It's quite amazing how well a little security by obscurity works to deflect these. My home's Internet-facing ssh server is bound to a high nonstandard port number, and it sees almost no probe traffic.

    The school one is on port 22 and sees a hell of a lot. I have fail2ban configured on that server, not because I'm worried about passwords being brute-forced (sshd has an inbuilt delay on login failure that deals effectively with that, given any decent password strength) but just to get rid of the syslog spam from failed login attempts.


Log in to reply