This is a discussion on RE: scp -t . - possible idea for additional parameter - openssh ; >Yes, and...? What does that accomplish in terms of security,>specifically?= I.e. what is the specific threat you are trying to protect>against? = It's pretty simple really, to not allow someone who is copying a file to go= anywhere outside of ...
>Yes, and...? What does that accomplish in terms of security,>specifically?=
I.e. what is the specific threat you are trying to protect>against?
It's pretty simple really, to not allow someone who is copying a file to go=
anywhere outside of the directory we started them in.
Why should anyone have to build out a hugely convoluted chroot'd environmen=
t to simply disallow someone from writing / reading from anywhere but their=
starting directory? Especially if we can simply, and effectively disallo=
w the use of "../" in the remote file path, as well as preface "./" to the =
remote path after the hostname.
If this *feature* were able to be set system wide, users who were allowed t=
o scp (ie, change their login shell to be "/usr/local/bin/scp -t .") only w=
ould never be able to write outside of their home directories, unless the s=
ystems admins had configured sym-links to point somewhere else.
Using keys, you could potentially allow a user to scp files to/from another=
directory, without having to create additional userids.
command=3D"/usr/local/bin/scp -t /some/path/to/write/to" .....public key...=
within the authorized keys file would do the trick nicely.
We can use this functionality today, minus the ability to lock the user int=
o the startup directory.
A simple (I hope) change to modify the remote path params, would finish thi=
s and make it extremely easy to lock the file transfer to the start directo=
Help yourself to FREE treats served up daily at the Messenger Caf=E9. Stop =
openssh-unix-dev mailing list