To quote from a previous post:

"Okay, so while it's possible to use SSH Public Key authentication to log into your system without entering a password (even if your home directory is encrypted), it's not possible to automatically mount your encrypted home directory."

This is the problem. While I appreciate that the password is used to unlock the passphrase, this means you need a password even when you arranged automatic login so you don't need a password. A better solution would be to use the remote authentication of the private key to unlock a second copy of the decryption passphrase and based on that unlock then allow the file system to be decrypted. In this way, I don;t need a password but only when an authorized and (public key) authenticated user logs in can the files be read.

"To solve this, you'll need to add a line to the end of your unmounted $HOME/.profile:

ecryptfs-mount-private This will ensure that after you've logged in using SSH Public Key authentication, you'll be prompted for your password and will mount your encrypted data. If it's already mounted, then this command should just silently succeed."

Except that it requires the password be typed. What should happen is that if your ssh succeeds, you should have access to the decrypted filesystem. So my question is, is there a work-around for this yet? Or lacking one, can someone who is in charge of that particular mechanism fix it to work this way?

  • I don't see the point of having an encrypted filesystem that automatically decrypts itself. I imagine the writers of that utility had the same thought. Remember that encryptfs doesn't know you just logged in, it just knows that command was issued to decrypt and to do that it expects a password
    – Huckle
    Apr 22, 2012 at 5:05
  • Just posted some guidelines [here][1]. [1]: stackoverflow.com/questions/22244611/….
    – VlatkoB
    Apr 16, 2015 at 6:49

1 Answer 1


This is not possible without either extending the SSH protocol, or implementing some other custom protocol.

First of all, the SSH private key is never made available to the system you are logging in to. Instead, your system signs a challenge with the private key and sends the signed challenge back to the remote system. Since the remote system has the public key on record, it can verify the signature and be satisfied that you hold the private key.

If you use an SSH agent, then it is possible to give the remote host limited access to your private keys by forwarding the agent connection (an act that has some risk: if the remote host has been compromised, they could use the forwarded agent connection to break into other systems you have access to). But again, this doesn't help since instead of revealing the private key, the SSH agent instead offers an interface for signing data provided by the client.

There was an option in the abandoned Secure Shell Authentication Agent Protocol Internet Draft to allow clients to ask the agent to decrypt some provided data, but that is not implemented by either the OpenSSH or Gnome Keyring implementations of the protocol. And even if it was, this would involve the remote system revealing the eCryptFS passphrase to a remote system, which has its own security considerations.

As you can see, it isn't a particularly simple problem, and would be difficult to just bolt onto the side of the existing utilities.

If you were happy to store the remote system's passphrase locally, then you might be able to write a script that would decrypt it and pipe it to ssh remotehost ecryptfs-add-passphrase - or similar, which should then allow the encrypted directory to mount.

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.