Results 1 to 9 of 9

Thread: Encrypted home not unlocked when logging in over SSH

Hybrid View

  1. #1
    Join Date
    Oct 2006
    Beans
    4,619
    Distro
    Kubuntu 14.10 Utopic Unicorn

    Encrypted home not unlocked when logging in over SSH

    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?
    Blog | Ubuntu User #15350 | Zsh FTW | Ubuntu Security | Nothing to hide?
    AMD Phenom II X6 1075T @ 3GHz, Nvidia GTX 650, 8GB DDR3 RAM, 2 X 1TB, 1 X 3TB HDD
    Please don't request support via PM


  2. #2
    Join Date
    Mar 2007
    Location
    Denver, CO
    Beans
    7,602
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: Encrypted home not unlocked when logging in over SSH

    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"]

  3. #3
    Join Date
    Oct 2006
    Beans
    4,619
    Distro
    Kubuntu 14.10 Utopic Unicorn

    Re: Encrypted home not unlocked when logging in over SSH

    Quote Originally Posted by kevdog View Post
    What is the command line you are running?
    I'm just running
    Code:
    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.
    Blog | Ubuntu User #15350 | Zsh FTW | Ubuntu Security | Nothing to hide?
    AMD Phenom II X6 1075T @ 3GHz, Nvidia GTX 650, 8GB DDR3 RAM, 2 X 1TB, 1 X 3TB HDD
    Please don't request support via PM


  4. #4
    Join Date
    Mar 2006
    Location
    Williams Lake
    Beans
    Hidden!
    Distro
    Ubuntu Development Release

    Re: Encrypted home not unlocked when logging in over SSH

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

  5. #5
    Join Date
    Oct 2006
    Beans
    4,619
    Distro
    Kubuntu 14.10 Utopic Unicorn

    Re: Encrypted home not unlocked when logging in over SSH

    Quote Originally Posted by cariboo907 View Post
    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.
    Last edited by FuturePilot; November 21st, 2009 at 05:38 AM.
    Blog | Ubuntu User #15350 | Zsh FTW | Ubuntu Security | Nothing to hide?
    AMD Phenom II X6 1075T @ 3GHz, Nvidia GTX 650, 8GB DDR3 RAM, 2 X 1TB, 1 X 3TB HDD
    Please don't request support via PM


  6. #6
    Join Date
    Feb 2005
    Beans
    10
    Distro
    Ubuntu 7.10 Gutsy Gibbon

    Re: Encrypted home not unlocked when logging in over SSH

    Quote Originally Posted by FuturePilot View Post
    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:
    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:

    Code:
    $ /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
    Last edited by kerignell; December 6th, 2009 at 11:38 PM.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •