39

I recently set up a new server with Ubuntu karmic 9.10, and when I created my home directory I chose to make it encrypted. Now, after loading my authorized_keys file into ~/.ssh, it isn't recognized because my home directory isn't decrypted until after I log in. Is there a way to make SSH keys work with encrypted home directories under Ubuntu?

3
  • Better tag suggestions welcomed, couldn't find really good matches in the suggested tags.
    – Josh
    Oct 26, 2009 at 20:06
  • 1
    i think those are spot on, actually. there's an ubuntu tag but i don't think this problem is specific to any particular OS. Oct 26, 2009 at 20:46
  • 1
    A symptom of this problem for me in Ubuntu 11.10 is that the first attempt to ssh into the machine is that password authentication is required (since authorized_keys is not accessible yet). If I launch another ssh connection, key authentication then works. Dec 22, 2011 at 14:58

6 Answers 6

40

Change this line in your sshd_config file:

AuthorizedKeysFile /etc/ssh/%u/authorized_keys

And then move your authorized_keys file to /etc/ssh/your-username/authorized_keys

This post documents another way to solve this.

3
  • 1
    I thought the first solution sounded perfect but it didn't work for me. Not sure why. But the post you linked to worked great. Thanks!
    – Josh
    Oct 27, 2009 at 13:20
  • 3
    Josh - is the target user the owner of those files, and permissions 600 (700 for the dir)?
    – NVRAM
    Nov 21, 2009 at 17:47
  • 2
    See this link for full instructions: SSH Keys on Ubuntu. Scroll down to the troubleshooting section.
    – jjeaton
    Aug 3, 2011 at 5:35
8

This solution was inspired by this post. IMHO it is much better than modifying your /etc/ssh/sshd_config since it doesn't require root access at all.

# Make your public key accessible
mkdir -m 700 /home/.ecryptfs/$USER/.ssh
echo $YOUR_PUBLIC_KEY > /home/.ecryptfs/$USER/.ssh/authorized_keys
ln -s /home/.ecryptfs/$USER/.ssh/authorized_keys ~/.ssh/authorized_keys
ecryptfs-umount-private
chmod 700 $HOME
mkdir -m 700 ~/.ssh
ln -s /home/.ecryptfs/$USER/.ssh/authorized_keys ~/.ssh/authorized_keys

# Make it auto-mount with first login.
# Note: it can cause problems with automated login.
echo /usr/bin/ecryptfs-mount-private > ~/.profile
echo cd >> ~/.profile
echo source .profile >> ~/.profile
ecryptfs-mount-private
3
  • 4
    Can you provide a summary statement of what this actually does? Dec 22, 2011 at 15:02
  • I made an edit to explain what happens: you save your public key(s) with which you want to access the machine to authorized_keys in /home/**.ecryptfs**/$USER without encryption and link to it from you encrypted home as well as your unencrypted home. The new .profile in your unencrypted home should mount your encrypted home directory, "cd" into it and source your real .profile.
    – LiveWireBT
    Jul 23, 2016 at 1:19
  • Works as intended on a new 16.04 installation. Few remarks: the unencrypted home was not writable (which makes sense, you don't want users to subvert everything by accidentally storing data there) so change the permissions temporarily. Also one has to do all of this from terminal, logged out of the GUI and lightdm or which ever DM you are using stopped. ecryptfs-mount-private asks for the user password every time after successful login via public keys unless you're logged into the GUI. My edit replaces a few echos with a here document, it's less repetitive to type, don't be confused by that.
    – LiveWireBT
    Jul 23, 2016 at 2:10
2

I just spent some time messing around with this, and the answer is that it's pretty much fundamentally impossible. It is possible to set up passwordless public-key-authenticated logins via ssh, so you don't have to type in your password to log in, but that doesn't get you anywhere, because your home directory is still encrypted.

The simple fact is that your encrypted home directory is encrypted with a password*, so the only way to decrypt it is with that password.

And if you're thinking that in theory it should be possible to use your ssh key to decrypt the mount passphrase upon login, that won't work because your private key is never sent to the server at all.

So basically, if you want encryption, you have to use passwords. Encrypted home directories are incompatible with fingerprint logins for the same reason.


*I know it's more complicated than a single password, but let's keep it simple for now.

9
  • Well, djhowell's answer worked perfectly so presumably my home directory is encrypted with a key the OS has and is able to use to decrypt it. Besides, when SSHing in, sshd doesn't know how to decrypt my home directrory, so that doesn't explain why it works with password authentication.
    – Josh
    Oct 27, 2009 at 13:23
  • Wait, so when you log in via ssh without typing any passwords, your encrypted home directory actually gets mounted? Oct 28, 2009 at 8:00
  • Yes, it does. And umounted when I log out.
    – Josh
    Oct 28, 2009 at 13:00
  • Well, that's odd. I get the behavior that I describe in my answer. My private dir only gets mounted if my login involved a password (specifically, my login password). I wonder what you did differently to get it to work with public keys. Oct 28, 2009 at 17:47
  • @Ryan Thompson are you using Ubuntu 9.10 ?
    – Josh
    Oct 28, 2009 at 22:16
2

If you don't like modifying the default setup (I don't, I like my files to be where I expect them to be) then you might want to take a look at my post on how to do that:

http://www.enetworkservices.net/wordpress/ssh-public-keys-with-encrypted-home-directory.html

In short. You put your keys in the encrypted version of your user ~/.ssh and symlink the encrypted version of ~/.ssh to the other. This way it's always there.

For the lazy people like myself, here's a script to do it for you. Just run it as the normal user. No root access or permissions needed and no server configuration changes required. Pure normal user settings.

#!/bin/bash
#
# Encrypted Home DIR SSH Key fix.
# Requires modification to sshd_config
#  AuthorizedKeys /etc/ssh/authorized_keys/%u/authorized_keys
# sudo mkdir /etc/ssh/authorized_keys -m 777
# for existing users run from home directory when login.
# for new users modify /etc/skel to include .bashrc to call script.
#
# Author: Benjamin Davis <[email protected]>

# Check if directory exists.
if [ ! -d "/etc/ssh/authorized_keys/$LOGNAME" ]
then
    # Make directory with restricted permissions.
    echo "Creating user ssh directory."
    mkdir /etc/ssh/authorized_keys/$LOGNAME -m 700
fi

# Check real users home .ssh folder
if [ -d "/home/$LOGNAME/.ssh" ]
then
    # Check if dir is symlink
    if [ ! -h /home/$LOGNAME/.ssh ]
    then
        echo "Moving configs."
        mv /home/$LOGNAME/.ssh/. /etc/ssh/authorized_keys/$LOGNAME/.
        rm -rf /home/$LOGNAME/.ssh/
        ln -s -T /etc/ssh/authorized_keys/$LOGNAME /home/$LOGNAME/.ssh
        clear
    fi
else
    # Does not exist so link it.
    if [[ $EUID -ne 0 ]]
    then
        echo "User ssh config folder does not exist. Creating."
        mkdir /home/$LOGNAME/.ssh -m 700
        ln -s -T /etc/ssh/authorized_keys/$LOGNAME /home/$LOGNAME/.ssh
    fi
fi
0

You can use the more secure public key to login, and then execute the following to mount your directory after typing in your password:

ecryptfs-mount-private

Read the ~/README.txt file after logging in via SSH, you'll find that you don't have your files because the encrypted directory is not mounted.

You shouldn't be using passwordless public-keys to login anyway. Look at ssh-agent for a better way.

0

my issue is related to authorized_keys

Observation - It was not possible to add new keys to .ssh/authorized_keys on Ubuntu. But worked like a charm on Amazon Linux.

On Ubuntu always getting a

-bash: ./.ssh/authorized_keys: Permission denied with cat ./.ssh/my-plublic-id_rsa.pub >> ./.ssh/authorized_keys

Not sure what I am missing.

PS: I had spun up 2 EC2 instances on AWS -

One running "Ubuntu 20.04.3 LTS" and Another running "Amazon Linux 2"

1
  • 1
    As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Dec 16, 2021 at 13:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .