3

There is seemingly a trick for creating read-only sshfs logins with the read only attribute is enforced by the remote's ~/.ssh/authorized_keys file.

You first create a program ~/.ssh/ro-sftp-server that runs sftp-server -R, which whatever other options were passed. You next set up your restricted ssh key as usual in the remote's ~/.ssh/authorized_keys file except adding a command restriction :

no-X11-forwarding,no-agent-forwarding,no-pty,command= “~/.ssh/ro-sftp-server” ssh-rsa ...

Finally, you mount the directory by invoking sshfs.

sshfs -o ssh_command="ssh -i ~/.ssh/ro_key" \
      -o sftp_server="~/.ssh/ro-sftp-server" \
      -o idmap=mrmeow -o ro \
      mrmeow@example.com:. ~/www/

Great! Now how do I permit writes but only after asking for a password?

I could certainly make autofs mount a second read-write sshfs volume on demand using a password protected but unrestricted key.

I'd finally need unionfs, mhddfs, or similar to make this second directory appear over the first, except apparently I'd need them both honestly mounted. :(

Any ideas about how one should achieve this "password prompt on write"? functionality?

Jeff Burdges
  • 156
  • 1
  • 7
  • 1
    Not all writes are initiated by a terminal application (or a GUI one for that matter). If John Doe's random cronjob tries to write to the filesystem at 3 AM is someone going to be there to type the passphrase? – voretaq7 Jan 29 '13 at 16:37
  • If you're logged out, the read-only sshfs session should be down as well, but yes probably writes should simply fail immediately but launch the second sshfs whenever they do so. In any case, there is a more fundamental difficulty that afaik unionfs, mhddfs, etc. all require that all the filesystems be mounted from the start. – Jeff Burdges Jan 29 '13 at 22:44
  • Can you tell us a little more about what you're doing Jeff? Your explanation (logged out = not mounted) just raises other potential cronjob issues (writing to a directory that will "disappear" the next time you log in and stuff mounts over it). If we knew more about your end goal we might be able to give you some ideas on how to make it work... – voretaq7 Jan 30 '13 at 05:20

1 Answers1

0

Fuse won't be able to give you a password prompt on the terminal because it has no access to it. You might be able to get Fuse to guess your X display and block I/O while it pops up a GUI password prompt. Some desktop environments (Gnome/KDE) provide wallet facilities for unlocking keys; they might be a good thing to connect to.

But for simplicity, may I suggest an alternative. Perhaps somewhere in your workflow you can check the need for write capability, and bring up the prompt using a script.

For example, if you use Vim you could check before you write a file:

autocmd BufWritePre *.c                         \
    let targetfile = expand('%')              | \
    if !filewritable(targetfile)              | \
        exec "!~/bin/prompt_remount_foo_rw"   | \
    end

Or in a fantasy Coffeescript build process, you could act accordingly after write errors:

buildProcess.on "error", (e) ->
    if e.writeError
        prompt_remount_foo_rw().then(retryBuild)

To get a prompt in a single terminal without X would require support from whatever software you are using to make the write.

joeytwiddle
  • 484
  • 4
  • 7
  • 2
    Almost all modern unix system ship with GUI "keychain" tools that manage ssh-agent credentials by password prompting on demand, although one should make ssh-agent forgetful by adding a -t option. In Mac OS X, you add this option in /System/Library/LaunchAgents/org.openbsd.ssh-agent.plist – Jeff Burdges Jan 29 '13 at 16:30