0

I found many guides on how to mount a NAS drive via fstab. Quite some enter username and password right into the fstab file, others use a file .smbcredentialsfor that.

I'd like to manage all my credentials with KeePassXC or some other portable database. Is there a way to tell the fstab fetching the username and password from such credential manager?

My probably-a-lot-of-work-around idea was, to use some kind of scriptfs (this one seems unmaintained, but maybe there is a modern alternative) to create a virtual filesystem, exposing a virtual file as proxy between the password store and the fstab (.smbcredentials). So any hints in this direction may be appreciated, if no simpler solution is available.

9
  • I have some ideas, but have some questions first. Are you using only a simple key file, or does it involve something more interactive (like OTP, 2FA, keyboard-inputted password, etc.)? How will your credentials be associated with mount points in KeePassXC, just using the hostname as the <entry>? Commented Jan 22 at 1:57
  • And which specific OS or distribution are you targeting this application for? Commented Jan 22 at 11:33
  • Did you resolve your problem? I've been working on a solution for you. Commented Jan 22 at 22:36
  • @Vercingatorix: Currently I have two databases, one only secured by keyfile, the second additionally with a password. I don't know what the best (or possible) way would be to associate the credentials with the mount point. Currently I run a MINT/i3, but currently looking into options as Arch or Suse. Commented Jan 23 at 10:55
  • 1
    I'm still working on a solution for you; almost done, I am very confident it works and will meet your requirements, but I need to wait until Monday to finish it. I have the part working that prompts for a key and pulls the credentials dynamically out of KeePassXC and mounts SMB volumes that way. Next step is mounting them automatically on use, and writing it up. Commented Jan 24 at 22:41

1 Answer 1

1

You'll need a few prerequisites, which I list at the end.

The simplest solution, which IMHO is not that much different from the fancy ones (as much time as I've spent contemplating the fancy ones), is to write a script to prompt (optionally) for a key, extract the credentials from KeePassXC, store them in the ramdisk in /dev/shm, do the mount, and overwrite and delete the entered key. I see no way of getting around putting the key in ramdisk and I argue it's not high-risk anyway.

Let's assume you have entries in your /etc/fstab like this (note the noauto, which prevents it from being mounted on boot):

//localhost/Shared /mnt cifs defaults,noauto,credentials=/dev/shm/smbcreds/localhost 0 0 

Here localhost in /dev/shm/smbcreds/localhost is the KeePassXC "Title" or "Entry" for the credential.

Besides linking the fstab entry to the database with the Title field, you'll need to update (or write) your entries in KeePassXC with a Notes field that starts with smb:<proper_domain> for each server. (If you foresee only one domain, modifying the script is left as an exercise to the reader.)

Copy this script and run it with sudo when you log in or whenever you want to do the mounts. Update the script with your credentials KeePassXC database.

#!/bin/bash # Modify your /etc/fstab like so: # //localhost/Shared /mnt cifs defaults,noauto,credentials=/dev/shm/smbcreds/localhost 0 0 # Then run this script as root creddir="/dev/shm/smbcreds" keyfilename=/dev/shm/kpxc.key passwdfile=<your KeePassXC database file> # Make sure no one can read key umask 077 # zenity may depend on some GNOME libraries. You can also try `yad`, mutatis mutandis, which depends on GTK+. # Grr. KeePassXC requires that the newline be stripped from the key, so we use awk. zenity --password --title="Enter KeePassXC key" | awk '{printf "%s", $0}' > ${keyfilename} # Create credential directory and make sure no one can read it mkdir -p -m 700 ${creddir} # Export all the keys in CSV format. Extract the title, username, # password, and notes, saving only those flagged as server # credentials, and iterate over them. for server in $(keepassxc-cli export -f csv -k ${keyfilename} --no-password ${passwdfile} | csvtool namedcols Title,Username,Password,Notes - | fgrep ',smb:'); do # Extract username, password, and domain, and write to a credential # with name of the first word on the line terminated by comma # (i.e. the Title) awk -F',' '{ split($4, params, ":"); printf ("username=%s\npassword=%s\ndomain=%s\n", $2, $3, params[2]);}' <<< "$server" > ${creddir}/${server%%,*} done # Zero out key just to be paranoid dd if=/dev/zero bs=$(stat --format %s ${keyfilename}) count=1 of=${keyfilename} >& /dev/null # and remove rm -f ${keyfilename} # Find all cifs targets and mount them (note: mount -a -t cifs doesn't work here b/c `noauto`) findmnt --fstab -t cifs -o TARGET --noheadings | xargs -I{} mount {} for cred in ${creddir}/*; do dd if=/dev/zero bs=$(stat --format %s ${cred}) count=1 of=${cred} >& /dev/null rm -f ${cred} done 

Of course, one downside to this solution is that the fstab credentials do not exist outside of executing the script. A scriptfs solution might help but you'd still need a semi-manual step before mounting to mount the scriptfs virtual filesystem and accept the key entry. But you'd have to keep the key around or re-enter it on every mount. Do you want to do that?

If you want an updated version of scriptfs to play with and are convinced it's the solution you want, conveniently, an updated version is available here. I can help with putting a script together for it.

Have you explored autofs? It automatically triggers a mount when you try to access a path associated with a mount point. The potential catch with autofs pertains to mounts that require an interactive key; unless you cached the key for a time, which I assume you do not want to do otherwise you wouldn't have the interactive requirement, you'd have to re-enter it for every individual mount request. I don't know how many of your mounts will require an interactive key. Depending on this, it might be easier to request the key, mount all the servers, then delete the key, which is what I assume you are doing now. Or if you're OK storing the interactive key indefinitely in ramdisk, you could do that.

Let me know what you think of this solution. I have a scriptfs solution in the wings and some ideas on using autofs but I need to get a better feel for your use case. I can update later with a better solution. There are a lot of directions we could go and I need to focus on one solution first and see how it fits.

Prerequisites:

sudo apt update sudo apt install csvtool sudo apt install zenity sudo apt install autofs # Optional 
2
  • Thanks a lot. I will try your solution as soon as I am home! Commented Feb 1 at 19:33
  • did you ever try this? Commented Mar 28 at 17:51

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.