Bug 3131 - [PATCH] Adding a chroot-directory option per key in authorized_keys file
Summary: [PATCH] Adding a chroot-directory option per key in authorized_keys file
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 8.2p1
Hardware: Other All
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-06 22:13 AEDT by David Shlemayev
Modified: 2020-03-07 18:38 AEDT (History)
2 users (show)

See Also:


Attachments
Patch file to add a per-key chroot-directory option (6.95 KB, patch)
2020-03-06 22:13 AEDT, David Shlemayev
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Shlemayev 2020-03-06 22:13:47 AEDT
Created attachment 3361 [details]
Patch file to add a per-key chroot-directory option

I'm trying to create a temporary sftp "inbox", so users can share
files more easily.
To do that I want the sender to generate a temporary key pair, send me
the public key securely (perhaps over TLS or a trusted third party),
then I can add a line in authorized_keys like this:

restrict,command="internal-sftp",chroot-directory="/run/ssh-inbox/1000/05b475...a592b2"
ssh-rsa AAAAB3NzaC...kIQX3jyJ2oM=

Which allows only sftp access to the following key, chrooted to the
given directory (which is owned by root, created by a daemon/suid
binary/etc), which is /run/ssh-inbox/<UID>/<SHA256(pubkey)>/
My patch verifies that the key has restrict and
command="internal-sftp" set before accepting the key.

I tried to stick to the surrounding code style as much as I could, let
me know if i need to fix anything.

Thanks,
- David
Comment 1 Damien Miller 2020-03-07 18:38:54 AEDT
AFAIK it's a bad idea to give the chroot ability to non-privileged users - there are a number of plausible paths to uid=0 if you can effectively write to / and /etc. This is why the chroot(1) syscall requires root privileges to begin with.

I appreciate your precaution of requiring force-command and sftp-server, but I'm not sure whether your need would be better served by putting a fake-chroot ability into sftp-server directly.