# pam_ssh, pam_ecryptfs and pam_mount

## [n00b@localhost]

A while ago I managed to set up pam_ssh so that when I logged in an ssh-agent would be started and my ~/.ssh/id_rsa added to it using my login password.

I recently decided to encrypt my ${HOME} directory using encryptfs and managed to get it to automatically mount when logging in locally using pam_ecryptfs and .profile, as directed in anrxc's blog post.  This worked for automatically mounting my encrypted home directory on login but left it mounted when I logged out and also broke my pam_ssh setup.  I believe it doesn't work on logout due to having hard-coded paths specific to Ubuntu in ecryptfs-utils.  (It also broke logging in remotely via ssh with a public/private key but I fixed that by setting AuthorizedKeysFile to /home/.ecryptfs/user/.ssh/authorized_keys in /etc/ssh/sshd_config.)

According to an article on the Arch Wiki I can get auto-unmounting working under a different setup to Ubuntu using the pam_mount module.  This would appear to use the pam_ecryptfs module to unwrap the passphrase upon login, then use pam_mount to mount the home directory, and automatically umount it on logout if and only if there are no other active logins.  I cannot get this to work though, either to automatically mount upon login, nor automatically umount on logout, and I still haven't been able to combine it successfully with pam_ssh.

Here is my /etc/pam.d/system_auth:

```

auth            required        pam_env.so 

auth            required        pam_unix.so try_first_pass likeauth nullok 

auth            required        pam_ecryptfs.so unwrap

#auth           optional        pam_mount.so debug

auth            optional        pam_permit.so

 

account         required        pam_unix.so 

account         optional        pam_permit.so

#password       optional        pam_mount.so debug

password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 

password        required        pam_unix.so try_first_pass use_authtok nullok sha512 shadow 

password        optional        pam_permit.so

session         optional        pam_ecryptfs.so

#session                optional        pam_mount.so debug

session         required        pam_limits.so 

session         required        pam_env.so 

session         required        pam_unix.so 

session         optional        pam_permit.so

```

In particular I am unsure of the order of the pam_ssh, pam_ecryptfs and pam_mount modules and their various parameters to get everything to work as I want.  I have included the debug option on the pam_mount module but there are no messages on login, indicating the module may not be getting invoked, while on logout I get [umount.ecryptfs] Failed to find key with sig [14acaa5eed663f1d]: Required key not available_ in /var/log/everything/current.

I also am frequently unable to umount my home directory (as root from the console) after logging out of KDE due to it still being accessed by a gam_server process which continues to run after KDE has exited.  How can I get it to stop?  Alternatively I can recompile KDE without requiring app-admin/gam-server by setting USE=-fam.  Does anyone know if this disables file alteration monitoring totally or will it fall back to using inotify provided by the kernel?

----------

## khayyam

 *[n00b@localhost] wrote:*   

> In particular I am unsure of the order of the pam_ssh, pam_ecryptfs and pam_mount modules and their various parameters to get everything to work as I want.

 

[n00b@localhost] ... I have some experience with both pam_mount and pam_ssh and I'm fairly sure you won't be able to use these in conjunction. The problem is that pam_ssh will need to access the key in ~/.ssh/ in order to authenticate, but the contents of $HOME isn't available as pam_mount hasn't mounted it ... as your not authenticated. Its a chicken/egg problem.

HTH & best ... khay

----------

## [n00b@localhost]

Thanks khay but I'm not interested in using pam_ssh for user authentication, just for starting an ssh-agent and loading ~/.ssh/id_rsa into it after ${HOME} has been mounted.

At the moment I can log in on the console and run mount -i ${HOME} to mount my home directory which means the ecryptfs fekek is being unwrapped successfully but pam_mount is unable to mount ${HOME} itself.  I can also run ssh-add which adds my ssh key to a running ssh-agent which means pam_ssh is starting the agent but is unable to find my key to add (probably because pam_mount failed).  This leads me to believe I'm almost there but that the order of statements in /etc/pam.d/system-auth is wrong or pam_mount is set up incorrectly (or, most likely, both).

The order I'm trying to achieve is this:

pam_ecryptfs unwraps ecryptfs fekek using login passphrase (achieved)

pam_mount mounts ${HOME} using unwrapped ecryptfs fekek (not achieved)

pam_ssh starts ssh-agent (achieved) and loads ssh key using login passphrase (not achieved)

Does that sound achievable?

Reading the documentation for pam_ecryptfs I didn't think I'd even be able to get this far as "pam_ecryptfs.so unwrap" unwraps the fekek passphrase and attempts to mount ${HOME} and I didn't think I'd be able to separate that behaviour.  The reason I'd rather use pam_mount is that it also automatically unmounts ${HOME} on logout, which pam_ecryptfs doesn't do unless you're on Ubuntu.

My /etc/security/pam_mount.conf.xml is:

```
<?xml version="1.0" encoding="utf-8" ?>

<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">

<!--

        See pam_mount.conf(5) for a description.

-->

<pam_mount>

                <!-- debug should come before everything else,

                since this file is still processed in a single pass

                from top-to-bottom -->

<debug enable="0" />

                <!-- Volume definitions -->

                <!-- pam_mount parameters: General tunables -->

<!--

<luserconf name=".pam_mount.conf.xml" />

-->

<!-- Note that commenting out mntoptions will give you the defaults.

     You will need to explicitly initialize it with the empty string

     to reset the defaults to nothing. -->

<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" />

<!--

<mntoptions deny="suid,dev" />

<mntoptions allow="*" />

<mntoptions deny="*" />

-->

<mntoptions require="nosuid,nodev" />

<!-- requires ofl from hxtools to be present -->

<logout wait="0" hup="0" term="0" kill="0" />                                                                                                                                      

                                                                                                                                                                                   

                                                                                                                                                                                   

                <!-- pam_mount parameters: Volume-related -->                                                                                                                      

<mkmountpoint enable="1" remove="true" />

<!-- User-specific configuration (from https://wiki.archlinux.org/index.php/ECryptfs) -->

<luserconf name=".pam_mount.conf.xml" />

<mntoptions require="" />

<lclmount>mount -i %(VOLUME) "%(before=\"-o\" OPTIONS)"</lclmount>

</pam_mount>
```

while my (anonymised) ~/.pam_mount.conf.xml is:

```
<pam_mount>

        <volume noroot="1" fstype="ecryptfs" path="/home/.ecryptfs/user/.Private/" mountpoint="/home/user/"/>

</pam_mount>
```

EDIT:

Actually, that's rubbish.  I haven't got pam_ssh to open an ssh-agent because I removed it from /etc/pam.d/system-auth while I get pam_mount working with pam_ecryptfs.  I did previously manage to get that far though.

----------

## khayyam

 *[n00b@localhost] wrote:*   

> [...] but I'm not interested in using pam_ssh for user authentication, just for starting an ssh-agent and loading ~/.ssh/id_rsa into it after ${HOME} has been mounted.

 

[n00b@localhost] ... your failing to understand how pam_ssh works, it is able to setup ssh-agent as it has the passphrase for the key provided as the login password ... AND it is the passphrase for that key that is accepted as the authentication (skipping whatever is held in /etc/passwd). It is the method of "user authentication" ... it simply uses the passphrase provided for the key ... but of course that key must be available prior to authentication (and so NOT on an encrypted volume).

 *[n00b@localhost] wrote:*   

> The order I'm trying to achieve is this:pam_ecryptfs unwraps ecryptfs fekek using login passphrase (achieved)
> 
> pam_mount mounts ${HOME} using unwrapped ecryptfs fekek (not achieved)
> 
> pam_ssh starts ssh-agent (achieved) and loads ssh key using login passphrase (not achieved)Does that sound achievable?

 

As I said previously, I can't see how this might work as so I'd have to say no. If pam_ecryptfs is using the "login passphrase" then where is pam_ssh getting the key passphrase from in order to setup ssh-agent? In order for pam_ssh to function at login it must has access to the key, and the passphrase provided for that key is used to authenticate. It simply won't work if the drive must first be mounted as the key, and so the authentication needed, isn't available. As I said, its a chicken/egg problem.

HTH & best ... khay

----------

## [n00b@localhost]

Well I've got most of it working!   :Smile: 

Here's my final /etc/pam.d/system-auth:

```

auth            required        pam_env.so 

auth            sufficient      pam_ssh.so

auth            required        pam_ecryptfs.so unwrap

auth            optional        pam_mount.so

auth            sufficient      pam_ssh.so try_first_pass

auth            required        pam_unix.so try_first_pass likeauth nullok 

auth            optional        pam_permit.so

 

account         required        pam_unix.so 

account         optional        pam_permit.so

password        optional        pam_mount.so

password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 

password        required        pam_unix.so try_first_pass use_authtok nullok sha512 shadow 

password        optional        pam_permit.so

session         required        pam_limits.so

session         sufficient      pam_ssh.so

session         optional        pam_mount.so

session         sufficient      pam_ssh.so

session         required        pam_env.so

session         required        pam_unix.so

session         optional        pam_permit.so

```

The first occurrence of pam_ssh in the auth section will succeed if the user's home directory is not encrypted and the passphrase matches the one for the user's ssh-key.  If so, the user is authenticated, an ssh-agent is started, keys are added and processing stops here.  If not then the passphrase is passed onto pam_ecryptfs which must be able to unwrap any encryptfs fekek in ~/.ecryptfs/wrapped_passphrase.  This will succeed if it is successfully unwrapped or does not exist.  Next, pam_mount is invoked to mount any user directories.  The only one that is defined is the encrypted ${HOME} which should be able to be mounted now the fekek is unwrapped.  This must succeed (or the passphrase is wrong for pam_ecryptfs).  Then, pam_ssh is invoked a second time now having access to the user's ssh keys on the encrypted volume.

Within the session module pam_ssh is listed either side of the pam_mount line.  On login, the first pam_ssh will fail with an encrypted directory as it is unable to write to ~/.ssh/agent-<hostname>.  The second invocation will succeed as it is after pam_mount.  Upon logout the first invocation of pam_ssh will kill the ssh-agent allowing pam_mount to unmount the volume.

The only thing that doesn't work is automatically adding ssh-keys upon login using an encrypted ${HOME}.  This is because the ssh-key used for authentication is passed to the first pam_ssh in the session section which fails.  It does not get passed on to the second pam_ssh.  I "solved" this using a startup script for KDE that calls ssh-add.

I also changed pam_mount.xml.conf to kill the stray gam_server process that hangs about after KDE quits in order to be able to unmount the volume.

It's a bit of a hack but it works!

----------

