hi,i have a question want to ask
if i add a user like:
useradd test groupadd test -g www
and how to control user test only can see and write only folder(like /home/htdocs/test,he can not see /home/htdocs or other folder)
thanks very much
2011/2/28 Yang Yang dapiyang@gmail.com:
hi,i have a question want to ask
if i add a user like:
useradd test groupadd test -g www
and how to control user test only can see and write only folder(like /home/htdocs/test,he can not see /home/htdocs or other folder)
for example using chrooted scponly or tweaking filesystem acls and selinux settings.
scponly chrooted is the easiest way.
-- Eero, RHCE
On Mon, Feb 28, 2011 at 10:53 AM, Eero Volotinen eero.volotinen@iki.fi wrote:
2011/2/28 Yang Yang dapiyang@gmail.com:
hi,i have a question want to ask
if i add a user like:
useradd test groupadd test -g www
and how to control user test only can see and write only folder(like /home/htdocs/test,he can not see /home/htdocs or other folder)
for example using chrooted scponly or tweaking filesystem acls and selinux settings.
scponly chrooted is the easiest way.
No, sftp is actually supported, somewhat, in OpenSSH 5 for this to work well, which is not in CentOS 5, and integrating it to CentOS 5 is problematic. It's also awkward to maintain, the chroot cages require the relevant binaries nad libraries in each user's chroot cage. (I used to publish the software changes for this, years back under SunOS and RedHat 5.2, not RHEL 5.2).
Frankly, don't. Use ftps, which Dovecot supports directly, or WebDav over HTTPS, which Apache supports directly with mod_dav.
On Tue, Mar 01, 2011 at 07:53:21AM -0500, Nico Kadel-Garcia wrote:
On Mon, Feb 28, 2011 at 10:53 AM, Eero Volotinen eero.volotinen@iki.fi wrote:
2011/2/28 Yang Yang dapiyang@gmail.com:
hi,i have a question want to ask
if i add a user like:
useradd test groupadd test -g www
and how to control user test only can see and write only folder(like /home/htdocs/test,he can not see /home/htdocs or other folder)
for example using chrooted scponly or tweaking filesystem acls and selinux settings.
scponly chrooted is the easiest way.
No, sftp is actually supported, somewhat, in OpenSSH 5 for this to work well, which is not in CentOS 5, and integrating it to CentOS 5 is problematic. It's also awkward to maintain, the chroot cages require the relevant binaries nad libraries in each user's chroot cage. (I used to publish the software changes for this, years back under SunOS and RedHat 5.2, not RHEL 5.2).
Frankly, don't. Use ftps, which Dovecot supports directly, or WebDav over HTTPS, which Apache supports directly with mod_dav.
I think you mean vsftpd? Problem with FTPS is that it *can* be problematic with firewalls (not necessarily your own which you can set up correctly, but on the client side).
ProFTPD may be a good option as well. It should have a mod_sftp module which theoretically could be used in tandem with ProFTPD's native chroot'ing stuff. Never tried it though.
Ray
Ray Van Dolson wrote:
ProFTPD may be a good option as well. It should have a mod_sftp module which theoretically could be used in tandem with ProFTPD's native chroot'ing stuff. Never tried it though.
I have - works well. You get all the fine-grain configuration options that ProFTPD has to control what users can and can't do with (s)ftp
James Pearson
On Tue, Mar 1, 2011 at 7:58 AM, Ray Van Dolson rayvd@bludgeon.org wrote:
On Tue, Mar 01, 2011 at 07:53:21AM -0500, Nico Kadel-Garcia wrote:
On Mon, Feb 28, 2011 at 10:53 AM, Eero Volotinen eero.volotinen@iki.fi wrote:
2011/2/28 Yang Yang dapiyang@gmail.com:
hi,i have a question want to ask
if i add a user like:
useradd test groupadd test -g www
and how to control user test only can see and write only folder(like /home/htdocs/test,he can not see /home/htdocs or other folder)
for example using chrooted scponly or tweaking filesystem acls and selinux settings.
scponly chrooted is the easiest way.
No, sftp is actually supported, somewhat, in OpenSSH 5 for this to work well, which is not in CentOS 5, and integrating it to CentOS 5 is problematic. It's also awkward to maintain, the chroot cages require the relevant binaries nad libraries in each user's chroot cage. (I used to publish the software changes for this, years back under SunOS and RedHat 5.2, not RHEL 5.2).
Frankly, don't. Use ftps, which Dovecot supports directly, or WebDav over HTTPS, which Apache supports directly with mod_dav.
I think you mean vsftpd? Problem with FTPS is that it *can* be problematic with firewalls (not necessarily your own which you can set up correctly, but on the client side).
*Yes*, yes, definitely my mistake. Thank your for correcting that.
I know FTP can be a nightmare: I thought FTPS had pretty much addressed the separate data and control channel issues, or am I profoundly mistaken?
ProFTPD may be a good option as well. It should have a mod_sftp module which theoretically could be used in tandem with ProFTPD's native chroot'ing stuff. Never tried it though.
Ray
I got vsftpd and httpd/mod_dav playing together well some years back, for someone who *insisted* on retaining FTP access for certain uses. It was.... a fascinating adventure to get them to play nicely.
On 2.3.2011 02:15, Nico Kadel-Garcia wrote:
I know FTP can be a nightmare: I thought FTPS had pretty much addressed the separate data and control channel issues, or am I profoundly mistaken?
Running ftp over ssl is not changing the ftp protocol. SSL or not, there are the same "open up a bunch of passive ports for data channel" insanities.
On 03/01/11 5:55 PM, Markus Falb wrote:
On 2.3.2011 02:15, Nico Kadel-Garcia wrote:
I know FTP can be a nightmare: I thought FTPS had pretty much addressed the separate data and control channel issues, or am I profoundly mistaken?
Running ftp over ssl is not changing the ftp protocol. SSL or not, there are the same "open up a bunch of passive ports for data channel" insanities.
and, worse, since the control channel is encrypted, this can't be done via a port monitor that sniffs and modifies 'port' commands, so this causes problems at BOTH ends of a NAT
On 2.3.2011 03:00, John R Pierce wrote:
On 03/01/11 5:55 PM, Markus Falb wrote:
On 2.3.2011 02:15, Nico Kadel-Garcia wrote:
I know FTP can be a nightmare: I thought FTPS had pretty much addressed the separate data and control channel issues, or am I profoundly mistaken?
Running ftp over ssl is not changing the ftp protocol. SSL or not, there are the same "open up a bunch of passive ports for data channel" insanities.
and, worse, since the control channel is encrypted, this can't be done via a port monitor that sniffs and modifies 'port' commands, so this causes problems at BOTH ends of a NAT
Could it be that the iptables ftp conntrack and nat modules does not work with ftps because of this ?
On 03/01/11 6:10 PM, Markus Falb wrote:
and, worse, since the control channel is encrypted, this can't be done
via a port monitor that sniffs and modifies 'port' commands, so this causes problems at BOTH ends of a NAT
Could it be that the iptables ftp conntrack and nat modules does not work with ftps because of this ?
exactly.
and, worse, since the control channel is encrypted, this can't be done via a port monitor that sniffs and modifies 'port' commands, so this causes problems at BOTH ends of a NAT
Could it be that the iptables ftp conntrack and nat modules does not work with ftps because of this ?
It is possible to instruct the FTPS client to keep the control channel in the clear so that firewalls that need to adjust to the ports being used can listen in on the conversation. The FTPS server has to agree to allow this to happen.
On 03/01/11 6:38 PM, Barry Brimer wrote:
It is possible to instruct the FTPS client to keep the control channel in the clear so that firewalls that need to adjust to the ports being used can listen in on the conversation. The FTPS server has to agree to allow this to happen.
aren't username/passwords sent in the clear then too? if so, whats the point of using ftps ?
On 03/01/11 6:38 PM, Barry Brimer wrote:
It is possible to instruct the FTPS client to keep the control channel in the clear so that firewalls that need to adjust to the ports being used can listen in on the conversation. The FTPS server has to agree to allow this to happen.
aren't username/passwords sent in the clear then too? if so, whats the point of using ftps ?
No, they are not. On the FTPS server you can require TLS encryption of everything, auth, data, control channel, nothing, or combinations of them. In this case you would require auth+data which would mean that your control channel is in the clear, but the username/password exchange and the data would be protected. You could also use an SSL client certificate as authentication and negate the need for the password to be sent altogether.
On Tue, Mar 1, 2011 at 10:16 PM, Barry Brimer lists@brimer.org wrote:
On 03/01/11 6:38 PM, Barry Brimer wrote:
It is possible to instruct the FTPS client to keep the control channel in the clear so that firewalls that need to adjust to the ports being used can listen in on the conversation. The FTPS server has to agree to allow this to happen.
aren't username/passwords sent in the clear then too? if so, whats the point of using ftps ?
No, they are not. On the FTPS server you can require TLS encryption of everything, auth, data, control channel, nothing, or combinations of them. In this case you would require auth+data which would mean that your control channel is in the clear, but the username/password exchange and the data would be protected. You could also use an SSL client certificate as authentication and negate the need for the password to be sent altogether.
*ouch*. Sounds like a lot of painful work and firewall negotiations to get right (which I've run into a few times lately with NAT's and slightly inconsistent NAT/firewall combinations this last year, though that was for FTP).
Those sorts of issues are why I've gotten fond of WebDAV over HTTPS.
On 1.3.2011 13:53, Nico Kadel-Garcia wrote:
On Mon, Feb 28, 2011 at 10:53 AM, Eero Volotinen eero.volotinen-X3B1VOXEql0@public.gmane.org wrote:
scponly chrooted is the easiest way.
No, sftp is actually supported, somewhat, in OpenSSH 5 for this to work well, which is not in CentOS 5, and integrating it to CentOS 5 is problematic.
Since CentOS 5.4(?) it is possible to say something like
Subsystem sftp internal-sftp ChrootDirectory %h
This is due to a somewhat partial backport of the chroot feature in OpenSSH. The problem I see is that it is global, no way to restrict the chroot to a group of users, so root is chrooted too. But if chrooted sftp is really required one could configure a second daemon listening on a different IP or maybe port.
https://rhn.redhat.com/errata/RHSA-2009-1287.html
It's also awkward to maintain, the chroot cages require the relevant binaries nad libraries in each user's chroot cage. (I used to publish the software changes for this, years back under SunOS and RedHat 5.2, not RHEL 5.2).
As far as sftp is concerned in newer openssh (and this is also true for the sftp in current CentOS) there is no need any more to maintain the chroot. Just configure sshd and you are ready to go.
On Tue, Mar 01, 2011 at 07:53:21AM -0500, Nico Kadel-Garcia wrote:
No, sftp is actually supported, somewhat, in OpenSSH 5 for this to work well, which is not in CentOS 5, and integrating it to CentOS 5 is problematic. It's also awkward to maintain, the chroot cages require the relevant binaries nad libraries in each user's chroot cage. (I used to publish the software changes for this, years back under SunOS and RedHat 5.2, not RHEL 5.2).
OpenSSH5 requires nothing inside the jail area for chroot sftp; that's why it's "sftp-internal".
2011/3/1 Stephen Harris lists@spuddy.org:
On Tue, Mar 01, 2011 at 07:53:21AM -0500, Nico Kadel-Garcia wrote:
No, sftp is actually supported, somewhat, in OpenSSH 5 for this to work well, which is not in CentOS 5, and integrating it to CentOS 5 is problematic. It's also awkward to maintain, the chroot cages require the relevant binaries nad libraries in each user's chroot cage. (I used to publish the software changes for this, years back under SunOS and RedHat 5.2, not RHEL 5.2).
OpenSSH5 requires nothing inside the jail area for chroot sftp; that's why it's "sftp-internal".
Is it possible to only chroot some users, not all.
-- Eero
On Tue, Mar 1, 2011 at 9:20 AM, Eero Volotinen eero.volotinen@iki.fi wrote:
2011/3/1 Stephen Harris lists@spuddy.org:
On Tue, Mar 01, 2011 at 07:53:21AM -0500, Nico Kadel-Garcia wrote:
No, sftp is actually supported, somewhat, in OpenSSH 5 for this to work well, which is not in CentOS 5, and integrating it to CentOS 5 is problematic. It's also awkward to maintain, the chroot cages require the relevant binaries nad libraries in each user's chroot cage. (I used to publish the software changes for this, years back under SunOS and RedHat 5.2, not RHEL 5.2).
OpenSSH5 requires nothing inside the jail area for chroot sftp; that's why it's "sftp-internal".
Is it possible to only chroot some users, not all.
They got that ***working***? I thought Theo had sworn that chroot cages would never be supported this way, as a "fundamentally wrong" approach!
On Tue, Mar 01, 2011 at 08:16:52PM -0500, Nico Kadel-Garcia wrote:
2011/3/1 Stephen Harris lists@spuddy.org:
OpenSSH5 requires nothing inside the jail area for chroot sftp; that's why it's "sftp-internal".
They got that ***working***? I thought Theo had sworn that chroot cages would never be supported this way, as a "fundamentally wrong" approach!
I've no idea of OpenBSDs SSH supports it, but OpenSSH portable does, and it works well as a way of providing *sftp only* locked down areas.
(chroot for shell access probably works as well, but not recommended for all the historical reasons - copies it various /lib files, /dev etc etc)
On 03/01/2011 11:53 PM, Nico Kadel-Garcia wrote:
On Mon, Feb 28, 2011 at 10:53 AM, Eero Volotineneero.volotinen@iki.fi wrote:
2011/2/28 Yang Yangdapiyang@gmail.com:
hi,i have a question want to ask
if i add a user like:
useradd test groupadd test -g www
and how to control user test only can see and write only folder(like /home/htdocs/test,he can not see /home/htdocs or other folder)
for example using chrooted scponly or tweaking filesystem acls and selinux settings.
scponly chrooted is the easiest way.
No, sftp is actually supported, somewhat, in OpenSSH 5 for this to work well, which is not in CentOS 5, and integrating it to CentOS 5 is problematic. It's also awkward to maintain, the chroot cages require the relevant binaries nad libraries in each user's chroot cage. (I used to publish the software changes for this, years back under SunOS and RedHat 5.2, not RHEL 5.2).
Frankly, don't. Use ftps, which Dovecot supports directly, or WebDav over HTTPS, which Apache supports directly with mod_dav. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I've used rssh for controlling SFTP access.
On Mon, Feb 28, 2011 at 05:53:34PM +0200, Eero Volotinen wrote:
2011/2/28 Yang Yang dapiyang@gmail.com:
hi,i have a question want to ask
if i add a user like:
useradd test groupadd test -g www
and how to control user test only can see and write only folder(like /home/htdocs/test,he can not see /home/htdocs or other folder)
for example using chrooted scponly or tweaking filesystem acls and selinux settings.
scponly chrooted is the easiest way.
I agree. Using scponly and some mount-binds would do the trick. The best way to do this, is to set scponly directory somewhere outside the /home/htdocs, and mount-bind only those directories from /home/htdocs, that that user can write to.
-
Barry Brimer -
Cameron Kerr -
Dominik Zyla -
Eero Volotinen -
James Pearson -
John R Pierce -
Markus Falb -
Nico Kadel-Garcia -
Philip Manuel -
Ray Van Dolson -
Stephen Harris -
Yang Yang