Encrypted home not unlocked when logging in over SSH

[FuturePilot]

I have a computer setup with SSH and my home directory encrypted with ecryptfs. The problem is that if I don't log in locally on the machine first, when I log in over SSH it doesn't decrypt my home directory. I have to manually run "ecryptfs-mount-private" which gets really annoying after awhile. I don't use password authentication, only key based authentication. I'm not sure if that is connected to the problem at all. Is this normal behavior? Is there a way to make it decrypt my home directory when I log in over SSH?

[kevdog]

What is the command line you are running?

Take a look at
/etc/sshrc
and
~/.ssh/rc

5.6.4. Arbitrary Actions with /etc/sshrc
When a user logs in, the normal Unix login system typically runs some shell scripts, such as /etc/profile. In addition, sshd runs the script /etc/sshrc for each SSH-based login. This feature lets the system administrator run special commands for SSH logins that don't occur for ordinary logins. For example, you can do some additional logging of SSH connections, print welcome messages for SSH users only, and set SSH-related environment variables. In all three, SSH1, SSH2, and OpenSSH, /etc/sshrc is processed by the Bourne shell ( /bin/sh) specifically, rather than the user's shell, so that it can run reliably for all accounts regardless of their various shells. It is run for logins (e.g., ssh my-host) and remote commands (ssh my-host /bin/who), just before the user's shell or command is invoked. It runs under the target account's uid, so it can't take privileged actions. If the script exits due to an error (say, a syntax error), the SSH session continues normally. Note that this file is run as input to the Bourne shell: sshd runs /bin/sh /etc/sshrc, not /bin/sh -c /etc/sshrc. This means that it can't be an arbitrary program; it must be a file containing Bourne-shell commands (and it doesn't need the execute mode bit set). /etc/sshrc operates machinewide: it is run for every incoming SSH connection. For more fine-grained control, each user may create the script ~/.ssh/rc to be run instead of /etc/sshrc. [Section 8.4, "The User rc File "] /etc/sshrc isn't executed if ~/.ssh/rc exists in the target account. Note that SSH rc files interact with X authentication. [Section 9.3.5.2, "xauth and the SSH rc files"]

[FuturePilot]

What is the command line you are running?

I'm just running

ssh user@host -p secret-port

Take a look at
/etc/sshrc
and
~/.ssh/rc

5.6.4. Arbitrary Actions with /etc/sshrc
When a user logs in, the normal Unix login system typically runs some shell scripts, such as /etc/profile. In addition, sshd runs the script /etc/sshrc for each SSH-based login. This feature lets the system administrator run special commands for SSH logins that don't occur for ordinary logins. For example, you can do some additional logging of SSH connections, print welcome messages for SSH users only, and set SSH-related environment variables. In all three, SSH1, SSH2, and OpenSSH, /etc/sshrc is processed by the Bourne shell ( /bin/sh) specifically, rather than the user's shell, so that it can run reliably for all accounts regardless of their various shells. It is run for logins (e.g., ssh my-host) and remote commands (ssh my-host /bin/who), just before the user's shell or command is invoked. It runs under the target account's uid, so it can't take privileged actions. If the script exits due to an error (say, a syntax error), the SSH session continues normally. Note that this file is run as input to the Bourne shell: sshd runs /bin/sh /etc/sshrc, not /bin/sh -c /etc/sshrc. This means that it can't be an arbitrary program; it must be a file containing Bourne-shell commands (and it doesn't need the execute mode bit set). /etc/sshrc operates machinewide: it is run for every incoming SSH connection. For more fine-grained control, each user may create the script ~/.ssh/rc to be run instead of /etc/sshrc. [Section 8.4, "The User rc File "] /etc/sshrc isn't executed if ~/.ssh/rc exists in the target account. Note that SSH rc files interact with X authentication. [Section 9.3.5.2, "xauth and the SSH rc files"]

Hmm that might work as a workaround. I noticed that if I use password authentication it automatically decrypts my home directory when I log in. But it doesn't if I use key based authentication. I wonder if this is a bug.

[cariboo]

Ssh can't read your keyfile because it's encrypted. move your key directory to an unencrypted portion of your home directory.

[FuturePilot]

Ssh can't read your keyfile because it's encrypted. move your key directory to an unencrypted portion of your home directory.

Logging in isn't the problem. I've already moved authorized_keys to my unencrypted home directory so that it stays in plain text. I can login over SSH fine, it's just that it doesn't decrypt my home directory. After doing some more searching, it seems that what I want to happen isn't possible (as of now). https://bugs.launchpad.net/ubuntu/+s...ls/+bug/364015. I guess I can hack something together with /etc/sshrc or ~/.ssh/rc to make it a bit easier.

[kerignell]

I guess I can hack something together with /etc/sshrc or ~/.ssh/rc to make it a bit easier.

Would you care to share that hack?

I tried to place a ~/.ssh/rc after unmounting the encrypted ~/, with this code:

#!/bin/sh

ecryptfs-mount-private 
sleep 1
exit 0

That one wont work.. But the command works when invoked manually.


To those of you who where in the situation of not being able to login unless logged in locally:
This drove me nuts for a while =). Solved it by moving a copy of my authorized_keys to the unencrypted ~/.ssh/ as per these instructions, from here:

$ /sbin/umount.ecryptfs_private
 $ cd $HOME
 $ chmod 700 .
 $ mkdir -m 700 .ssh
 $ chmod 500 .
 $ echo $YOUR_REAL_PUBLIC_KEY > .ssh/authorized_keys
 $ /sbin/mount.ecryptfs_private

Note, by $YOUR_REAL_PUBLIC_KEY he means the raw content of your id_rsa.pub/id_dsa.pub