1

I often work with remote hosts on multiple devices, mostly Windows and Linux machines. To avoid deploying my SSH keys everywhere, and circumvent the hassle of syncing SSH configuration, I put my SSH config file and keys in a Bitlocker encrypted NTFS partition in my pen drive.

I use include inside the SSH config on my working machines so that I can only access the remote hosts on the machine where my pen drive is plugged in and decrypted. Under Linux, NTFS mount options uid=1000,dmask=077, fmask=177 are used so the config file and SSH keys have the correct permission.

The problem is with the SSH client on Windows. The client complains about bad permission unless the owner of the key files is the current user, and there is no other user who has access to the files (see this post for details). Unlike the UNIX system, where uid=1000 refer to the default user in most cases, the NTFS permission object defined is not shared across the system. Therefore, when the pen drive is plugged into another Windows machine, the file is owned by Account Unknown(S-1-5-21-235848236-322578882-4173758772-1003), which does not work. The only solution I have right now is to manually change the ownership and permission of the files every time I switch my pen drive to another Windows machine.

I am looking for suggestions on improving my current setup. Any help is appreciated.

Update:

I tested and SSH does not even work with OWNER RIGHTS of NTFS.

2
  • There really isn’t a way to get around the permissions requirements on the key files. If the key files are not correct and owned by the user only the key file cannot be used
    – Ramhound
    Mar 21 at 9:33
  • OpenSSH is quite clear on permissions of keys, as they should not be accessible to anyone but the user. Best way I've found to manage SSH keys is to use a YubiKey, storing the SSH key in the A[uthentication] slot (@user1686's Suggestion #4); while OpenSSH supports hardware keys, I'm unsure how to directly configure it to access a PAM without 3rd party software (gpg || Gpg4Win with Kleopatra loaded). @User1686's Suggestion #1 seems the simplest and most efficient way to go about this. General FYI: SSH key best practice is to encrypt the key, negating the need for an encrypted container.
    – JW0914
    Mar 21 at 11:28

1 Answer 1

2

Suggestion 1: Automate the changing of ownership – e.g. make a wrapper batch script that runs icacls foo /setowner every time before actually starting OpenSSH. You don't need to have administrator rights for this if the file's NTFS ACLs explicitly grant "Change Ownership" permissions.

Suggestion 2: Use FAT32 or exFAT instead of NTFS for the encrypted volume. There are no file owners in exFAT. There's not much advantage in using NTFS for a small volume whose contents change rarely.

Suggestion 3: Have a different key on each client, and store the "main" key on a single trusted machine. Whenever you need it, ssh -A to that machine (using the client system's own key) and ssh-add the key. (This probably won't work very well with Windows ssh-agent, due to its persistent storage. Well, it'll still work, as long as you remember to remove the key again.)


Suggestion 4: Instead of carrying a raw key file around (encrypted or not), store it on a hardware token.

  1. Obtain a Yubikey, specifically a model with PIV smartcard emulation (YK5, YK4, YKNEO). Non-Yubikey USB tokens will also work as long as they can emulate a PIV smartcard (it has the advantage of being "mostly driverless" due to open specification) – not an OpenPGP smartcard.

  2. Import your SSH key into the smartcard (e.g. using Yubikey Manager).

  3. Configure your Windows OpenSSH to use PKCS11Provider libykcs11.dll which comes from the "yubico-piv-tool" package. The module doesn't need installation, so you can carry it around. Related blog post

    For Linux, configure OpenSSH to use either PKCS11Provider libykcs11.so (again from yubico-piv-tool) or alternatively opensc-pkcs11.so (which is part of OpenSC, which you probably already have).

  4. Also carry a copy of PuTTY-CAC (or just Pageant-CAC), which allows PuTTY and WinSCP support smartcards through both Windows CNG and PKCS#11 (which means it can natively access PIV cards).

The advantage of this method is that a even malicious machine (or a malicious ssh.exe) cannot steal your key the moment you unlock the BitLocker volume.

1
  • Suggestion 2 is actually the first thing I've tried. Unfortunately, although the files have no owner theoretically, I see on the details tab (no security tab) the owner is everyone, and SSH complains about bad permission. I wonder if anyone has luck with the SSH key on exFAT or FAT32. Mar 23 at 2:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.