sftpsh is a shell replacement that restricts users to using the sftp subsystem of ssh. There is currently no ebuild for this usefull little application. Reproducible: Always Steps to Reproduce:
Created attachment 28413 [details] ebuild for sftpsh Attaching an ebuild for evaluation.
(this is an automated message based on filtering criteria that matched this bug) Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Will review and test ASAP.
Hehe, haven't maintained this for a very, very long time now. Would be interesting to know if it still works as is. If there are people with need (want) for this I'll see if I can fix it up again if it doesn't work "as is" (quick review of the code makes me think it should just work). If there is no longer a need we can just close this and be done with it. Also, I've done alternative hacks now that uses the command= in .ssh/authorized_keys for automated configurations, but that doesn't work for end-users that just needs to be able to use something like winscp to upload/download files (and insists on using usernames+passwords) and that should not have shell. So there might still be requirement for this. J
Created attachment 235883 [details] Improved ebuild New version of the ebuild: * correct Copyright * correct LICENSE * use tc-getCC due to useless Makefile. Use doecho() from app-misc/sl * respect *FLAGS * correct DEPEND and RDEPEND However this app might overlapp with the ChrootDirectory functionnality of >=openssh-4.8
What's wrong with the Makefile? I'll happily make updates to this, it's been a while but I'm more than willing to "fix" things if it's possible. There was a reason for the direct dependency on glibc, I honestly can't remember what though, so I agree with that change. In fact, I like all the changes except: * use tc-getCC due to useless Makefile. Use doecho() from app-misc/sl * respect *FLAGS Which I believe is probably better to just fix the Makefile to do these things. However, the tc-getCC solution is definitely valid and the simpler change :).
(In reply to comment #6) > What's wrong with the Makefile? I'll happily make updates to this, it's been a > while but I'm more than willing to "fix" things if it's possible. > Yeah, I prefer to fix too. But woo, look at that: >cc=g++ >cflags=-Wall >sftpsh : sftpsh.c > ${cc} ${cflags} -o $@ $+ Patching 3 lines when we need a one-liner to compile the single source file respecting the *FLAGS. The doecho is of course only useful if you want to see the commandline being executed. > There was a reason for the direct dependency on glibc, I honestly can't > remember what though, so I agree with that change. In fact, I like all the > changes except: > Ok.
You're forgetting you're talking with the guy running svn repo. Just need to actually boot that machine again and port it to git (hosted on a server that's up 24/7) so that I can "fix" that Makefile the right way :). For the moment, leave your changes as is, and if you can get it into the tree that way, by all means. Hehe, looking at that Makefile again takes me back a few years ... :p
Is anyone still interested in this? I believe this has been obsoleted by OpenSSH itself. These days, in sshd_config, I use something like: Match group website_sftp ChrootDirectory /var/www/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp The "ForceCommand internal-sftp" makes sure that the user can only run SFTP and not get a full shell.
Hi, (In reply to Michael Orlitzky from comment #9) > Is anyone still interested in this? I believe this has been obsoleted by > OpenSSH itself. These days, in sshd_config, I use something like: > > Match group website_sftp > ChrootDirectory /var/www/%u > X11Forwarding no > AllowTcpForwarding no > ForceCommand internal-sftp > > The "ForceCommand internal-sftp" makes sure that the user can only run SFTP > and not get a full shell. I wrote the original code and I'm not interested in this any more. I'm closing, we're also using a variation of the above - the only advantage currently of sftpsh over the above is the fact that it doesn't require the ChrootDirectory to be root owned (the logic of which I quite frankly don't quite understand), from the man page for ChrootDirectory: Specifies the pathname of a directory to chroot(2) to after authentication. At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group. After the chroot, sshd(8) changes the working directory to the user's home directory. In the case of providing a shell I guess this could make sense, in the sftp world where there is nothing inside there except user owned files checking the last component (%u) doesn't make much sense in my personal opinion.
(In reply to Jaco Kroon from comment #10) > > I wrote the original code and I'm not interested in this any more. I'm > closing, we're also using a variation of the above Ok, thanks! > the only advantage > currently of sftpsh over the above is the fact that it doesn't require the > ChrootDirectory to be root owned (the logic of which I quite frankly don't > quite understand), from the man page for ChrootDirectory: > > ... > > In the case of providing a shell I guess this could make sense, in the sftp > world where there is nothing inside there except user owned files checking > the last component (%u) doesn't make much sense in my personal opinion. I think the issue is that the user can overwrite a directory that he owns. If I'm supposed to be chrooted in /var/chroot/mjo, but I own that directory, then I can overwrite it with a symlink to / and log out/in to escape the chroot. I've never tried that with sftp, but it works with a shell.
