I am trying to beef up my security on a remote NUC running Slackware 14.1 by no longer allowing password logins via SSH...and only allowing public key authentications.

I was able to log in remotely and generate the keys; however, what I soon realized was that when trying to transfer the keys via SFTP, ecryptfs does not mount my private directory, leaving the keys stranded because I couldn't find a way to send ecryptfs-mount-private to the NUC's shell via SFTP.

Whenever I log in via SSH, ecryptfs automatically mounts my encrypted directory.

I tried to run ecryptfs-umount-private while SSH'd in (to add the mount directive to ~/.profile as suggested here, even though it is an Ubuntu forum), but any calls to anything ecryptfs produce command not found from bash.

This is puzzling to me because when I SFTP in, I see the text file instructing me to run ecryptfs-mount-private. Slackware's implementation of ecryptfs must not allow tinkering with encrypted home directories?

Is there any way to retrieve my authentication keys remotely via SFTP, or is it just not possible to unmount the encrypted filesystem in SSH to induce configuration via unmounted ~/.profile?

Even if I was able to create an unmounted ~/.profile, would Slackware even care?

What if you're ssh'ed in, and then you connect via sftp? Then it should leave your directory mounted. Although, I must admit, I don't use encryption, so I am not sure how everything mounts and is accessible when using different protocols.

Another option is to put the file in another location using sftp that should be accessible once you log in, maybe /tmp, and then log in via ssh and move it to the correct location.

Hi. There are things I don't understand in your post...

First of all, why are you generating ssh key-pairs on the destination NUC? You should be generating the client auth key-pair on the client
and sending the public part to the NUC using your preferred method (e.g. ssh-copy-id).

Once that's set up you'll have an issue because my understanding is ecryptfs-utils helper scripts rely on login passwords to unwrap ecryptfs
passphrases and auto-mount. Obviously, that info isn't transmitted during password-less (i.e. pubkey) ssh authentication. You'll need another
way to trigger/effect the unwrap.

Finally, you can't execute remote shell commands with SFTP, if you need to do that use ssh.

Afaik, the only way to safely auto-mount ecryptfs homedirs is using a PAM module that gets called on login. Slackware doesn't ship PAM
so please describe how you've set up auto-mount on Slackware.

Slackware provides vanilla kernel-land ecryptfs as shipped by Linux (i.e. ecryptfs.ko). It doesn't provide the user-land utilities. In other
words, there is no such thing as a "Slackware implementation" of ecryptfs - at least no official one.

--mancha

1 members found this post helpful.

Reviewing my notes, you are absolutely correct. I haven't done this in awhile, and I may have confused my last configuration/setup on a different system where I had to generate the keys on the server side in order to ssh in from a non-jailbroken iPhone.

This is what the ubuntu forums were referring to...from what I've read, the command run from unencrypted ~/.profile prompts for a password to unwrap once logged in from SFTP.

I actually tried to install ecryptfs-utils from source (in order to get the ecryptfs-umount-private and ecryptfs-mount-private scripts), but configure failed due to PAM not being installed.

I haven't set up auto-mount on Slackware, I just happened to notice that my [encrypted] home directory is mounted when I SSH into the machine; but not mounted when I SFTP into it. Perhaps Slackware did some automagic configuration behind the scenes when I selected to encrypt my home directory during setup?

Unfortunately, the user-land utilities would have helped me in this case...

Thanks for your insight, mancha...I'll try again from the client-side to see if I can't get the keys stored that way.

Cheers,