mosh interacts poorly with PAM

[rhazegh]

Ubuntu 12.04 with the latest updates, Vim version 7.3.429
Mosh server (Ubuntu, amd64), Version: 1.2.4-0931precise1

Mosh client (osx): 1.2.4 (installed via brew)

• When I ssh to the Ubuntu box, I can run vim and quit vim with no problem.
• But, when I mosh to the Ubuntu box and run vim, I get this message when I try to quit vim: E138: Can't write viminfo file /home/my_account/.viminfo!

Any idea what is going on here?

[andersk]

Is your home directory on a networked filesystem (AFS, NFS, etc.) that requires authentication? Also, did you check that .viminfo didn't accidentally become owned by root (try ls -l .viminfo)?

[rhazegh]

Is your home directory on a networked filesystem (AFS, NFS, etc.) that requires authentication?

No. It's on a local hard disk. The home folder is encrypted with eCryptfs.

Also, did you check that .viminfo didn't accidentally become owned by root (try ls -l .viminfo)?

The file is not owned by root:

-rw------- 1 my_account my_account 625 May 25 17:06 .viminfo

If the problem was file permission, I suppose the same error should have happened when I used ssh.

[rhazegh]

I found the issue:

• When I ssh to the Ubuntu box, the encrypted home folder gets mounted automatically.
• But when I mosh to the Ubuntu box, the encrypted home folder is not mounted automatically. If I mount it with ecryptfs-mount-private the problem goes away.

[andersk]

Ah, eCryptfs. What actually happens is that pam_ecryptfs maintains a session counter (/dev/shm/ecryptfs-$USER-Private) that is incremented on PAM login and decremented on PAM logout. The temporary SSH session that mosh uses to launch the remote mosh-server causes a PAM login followed immediately by a PAM logout, so the counter reaches zero and the encrypted folder is unmounted immediately.

I don’t think that running a PAM session as a non-root user is a supported operation, so mosh-server itself cannot cause a PAM login. But this is a problem we’d like to solve, even if we don’t currently have a good solution, so I’ll reopen this in case someone has ideas.

[andersk]

(As an example of the kind of amazing horrible things that go spectacularly wrong if you try to run a PAM session as non-root, I just filed LP #1323421 “pam_ecryptfs returns twice from fork in error conditions”.)

[diepes]

Prevent auto unmount by deleting ~/.ecryptfs/auto-umount

[mek-apelsin]

While running mosh 1.2.4a:
local$ mosh remote
remote(encrypted)$ cat /dev/shm/ecryptfs-$USER-Private
0
remote(encrypted)$ ecryptfs-mount-private
FAIL
remote$ cat /dev/shm/ecryptfs-$USER-Private
1
remote(encrypted)$ ^D
local$ ssh remote cat /dev/shm/ecryptfs-$USER-Private
2 (WTF 1)
local$ mosh remote
remote(unencrypted)$ (WTF2)
remote$ cat /dev/shm/ecryptfs-$USER-Private
1 (WTF 3)
remote(encrypted)$ ^D
local$ ssh remote cat /dev/shm/ecryptfs-$USER-Private
2 (WTF 4)

This is with a totally empty but existing.profile, both in the encrypted and the unencrypted home-folder on remote. Why does the counter add one when disconnecting and subtract one when connecting?

[andersk]

That’s not what’s going on. ssh increments the count by 1 when opening the session, and decrements the count by 1 when closing the session. When you ran ssh remote cat /dev/shm/ecryptfs-$USER-Private, the cat ran between this increment and decrement pair. mosh uses a short-lived ssh session to create the session, which increments and then immediately decrements the count, leaving it net unchanged.

[cgull]

We'd still like to find a better fix for this, but tonight @eminence mentioned a half-decent workaround on #mosh: ssh localhost upon connecting to the remote host. mosh remote-host-name ssh localhost will often work as well.

This won't work all the time, but when it does you still get most of the benefits of mosh.