rssh-discuss Mailing List for rssh (Page 3)
Brought to you by:
xystrus
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(1) |
Jul
(15) |
Aug
(33) |
Sep
(5) |
Oct
(15) |
Nov
(8) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(5) |
Feb
|
Mar
(5) |
Apr
(4) |
May
(4) |
Jun
(15) |
Jul
(9) |
Aug
(11) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(6) |
2005 |
Jan
(8) |
Feb
(6) |
Mar
(43) |
Apr
(2) |
May
(5) |
Jun
(6) |
Jul
(12) |
Aug
(22) |
Sep
(5) |
Oct
(7) |
Nov
(15) |
Dec
(5) |
2006 |
Jan
(60) |
Feb
(7) |
Mar
(12) |
Apr
(7) |
May
(5) |
Jun
(14) |
Jul
(19) |
Aug
(21) |
Sep
(16) |
Oct
(2) |
Nov
(15) |
Dec
(3) |
2007 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
|
Jun
(26) |
Jul
(12) |
Aug
(1) |
Sep
(7) |
Oct
(2) |
Nov
|
Dec
(1) |
2008 |
Jan
(4) |
Feb
(6) |
Mar
(4) |
Apr
(4) |
May
(5) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(27) |
Mar
(20) |
Apr
(8) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
(4) |
Jul
(7) |
Aug
(6) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(16) |
May
|
Jun
(6) |
Jul
(20) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
|
Dec
(7) |
2012 |
Jan
(5) |
Feb
|
Mar
(9) |
Apr
|
May
(6) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(6) |
2013 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
|
2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(7) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2019 |
Jan
(8) |
Feb
(17) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2021 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: kaazoo <ka...@ke...> - 2016-03-08 16:47:57
|
Hello all, I've created a patch which adds ZFS support to rssh: https://gist.github.com/kaazoo/1358e893033f536802f9 This is useful if you want to replicate ZFS filesystems/volumes via snapshot send / receive over SSH. I would be very nice if you could include it in a future release. Regards, kaazoo |
From: Derek M. <co...@pi...> - 2015-11-19 18:03:27
|
On Thu, Nov 19, 2015 at 07:32:29AM -0500, Nico Kadel-Garcia wrote: > I hope you didn't mind my posting the link! No, of course not, not at all. > Please reconsider this policy. I've considered it several times already, and arrive at the same conclusion each time. That's unlikely to change. > I admit I don't currently maintain any real UNIX systems. (Not that > I haven't, my first UNIX was BSD 4.2!) The tools likely to be > created when "doing it by hand anyway" are likely to be unwieldy and > undocumented. and to fail flat-out fail for reasons that new > engineers may be unaware of. But your tools don't really help them, unless they're on one of a very specific set of platforms. That's the point: there's no universal way to do this right. Also, if you're going to be administering a setup like this, you should really UNDERSTAND what you're doing so you don't botch it. > I'm happy to maintain these for now: it just seems logical to bundle > them with rssh, for discoverability by new administrators, for > availability with Fedora and Debian, where the software is avaialble > bundled up. Those distros can provide whatever tools they want, specific to their own configurations. You should lobby them, not me. ;) IIRC I do provide a sample script that illustrates the gist of how to do it... it's left as an exercise to the admin to figure out the details on the relevant platform. And like I said, I don't maintain a contribs directory because I have no way to test those tools, and frankly wouldn't want to do it even if I could, and don't want people bugging me about it. That's why this list exists... if people are having trouble, they can ask other experienced users for help. The list is archived and searchable, so new people can benefit from old answers. And that, as far as I'm concerned, is the right way to solve the problem. Security is hard; if you don't understand what you're doing, you WILL get it wrong... every time. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Nico Kadel-G. <nk...@gm...> - 2015-11-19 12:32:36
|
On Wed, Nov 18, 2015 at 3:06 PM, Derek Martin <co...@pi...> wrote: > On Wed, Nov 18, 2015 at 06:06:59AM -0500, Nico Kadel-Garcia wrote: >> I published some tools to set these up some time ago, including an >> enhanced "mkchroot.sh" tool and and a "mkchroot-passwd.sh" tool for >> just this sort of setup at https://github.com/nkadel/rssh-chroot-tools >> >> If anyone wants to take on real maintenance for rssh, I'd love to >> see those tools lintegrated. > > The reason I never integrated any such tools is because they are > inherently platform-specific, and/or environment-specific. Your tools > appear to be specific to red hat distros which are installed with > default installs, but they probably won't work on customized installs, > or any number of other distros of varying ages, and almost certainly > won't work on any other flavor of Unix--all of which are (at least in > theory) supported by RSSH. The problem could be addressed with, say, > a heirarchical contrib directory of tools which are careful to take > lots of parameters for flexibility; but I didn't want to maintain > that, especially since I can't test it (and wouldn't want to, even if > I could). It could, *in theory*, also be addressed by a single set of > tools that knows what to do for all the various platforms and takes > all relevant paths as options... but in my mind such a tool would be > so unweildy to use that you'd be better off doing it by hand anyway. > ;) I hope you didn't mind my posting the link! Please reconsider this policy. I admit I don't currently maintain any real UNIX systems. (Not that I haven't, my first UNIX was BSD 4.2!) The tools likely to be created when "doing it by hand anyway" are likely to be unwieldy and undocumented. and to fail flat-out fail for reasons that new engineers may be unaware of. I'm happy to maintain these for now: it just seems logical to bundle them with rssh, for discoverability by new administrators, for availability with Fedora and Debian, where the software is avaialble bundled up. > Frankly, I don't think integration of such tools into the code base > makes sense, for those reasons. It seems like a separate, > complementary software project to me. That's what a "contribs" directory would be ideal for. I agree that it is complementary, but rssh is fairly useless without chroot cage building tools, and I've seen the mangled mash that new engineers come up when first confronted with the problem. Symlinks, hardlinked together and symlinks replaced with hardlinks and separate copies: it wasn't petty..... |
From: Derek M. <co...@pi...> - 2015-11-18 20:06:10
|
On Wed, Nov 18, 2015 at 06:06:59AM -0500, Nico Kadel-Garcia wrote: > I published some tools to set these up some time ago, including an > enhanced "mkchroot.sh" tool and and a "mkchroot-passwd.sh" tool for > just this sort of setup at https://github.com/nkadel/rssh-chroot-tools > > If anyone wants to take on real maintenance for rssh, I'd love to > see those tools lintegrated. The reason I never integrated any such tools is because they are inherently platform-specific, and/or environment-specific. Your tools appear to be specific to red hat distros which are installed with default installs, but they probably won't work on customized installs, or any number of other distros of varying ages, and almost certainly won't work on any other flavor of Unix--all of which are (at least in theory) supported by RSSH. The problem could be addressed with, say, a heirarchical contrib directory of tools which are careful to take lots of parameters for flexibility; but I didn't want to maintain that, especially since I can't test it (and wouldn't want to, even if I could). It could, *in theory*, also be addressed by a single set of tools that knows what to do for all the various platforms and takes all relevant paths as options... but in my mind such a tool would be so unweildy to use that you'd be better off doing it by hand anyway. ;) Frankly, I don't think integration of such tools into the code base makes sense, for those reasons. It seems like a separate, complementary software project to me. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Nico Kadel-G. <nk...@gm...> - 2015-11-18 11:07:12
|
On Wed, Nov 18, 2015 at 12:43 AM, Елизавета Остолоповa <1ad...@ma...> wrote: > About my previous email: > > I guess the problem is that scp does not automatically select the user's > home directory. I have to manually specify it. > scp document ap...@ex...:homedir/. > This works. > But this does not work: > scp document ap...@ex...:. > Normally this should work. So my question is how can I have scp to choose > the user's home directory automatically? > I tried to change the user home dir both in > /etc/passwd > and in > /usr/chroot/etc/passwd > Neither did not work. I published some tools to set these up some time ago, including an enhanced "mkchroot.sh" tool and and a "mkchroot-passwd.sh" tool for just this sort of setup at https://github.com/nkadel/rssh-chroot-tools If anyone wants to take on real maintenance for rssh, I'd love to see those tools lintegrated. |
From: Martin Y. <yve...@el...> - 2015-11-18 07:16:52
|
Hello, The home directory of user accounts must be inside chroot to work properly. For instance, in system /etc/passwd apple:x:1001:1001::/usr/chroot/home/apple:/usr/bin/rssh Then also define home directory inside chroot in /usr/chroot/etc/passwd apple:x:1001:1001::/home/apple:/bin/false Here, I use "/bin/false" as I do not expect users to start interactive shell inside chroot. Of course you have to: chown -R apple /usr/chroot/home/apple With these two "passwd" settings, you can browse "/usr/chroot/home/apple" from your host system with proper handling of UID/GID, and applications allowed to run by rssh inside chroot have required information about user too. Regards Yves Martin On Wed, 2015-11-18 at 08:43 +0300, Елизавета Остолоповa wrote: > On Debian 8.2 > I created a chroot using the supplied script. > > cat /etc/rssh.conf > ..... > user = "apple:011:100010:/usr/chroot" > > cat /usr/chroot/passwd > apple:x:1001:1001::/mnt/apple:/usr/bin/rssh > > Now when I upload a file using scp, it gives permission denied. When I > do this: > mkdir /usr/chroot/orange > chmod 777 /usr/chroot/orange > > scp document ap...@ex...:/orange/. > > it works. It does upload. What is the problem here? Even if I give 777 > permissions to /mnt/apple it gives permission denied. > > I guess the problem is that scp does not automatically select the > user's home directory. I have to manually specify it. > scp document ap...@ex...:homedir/. > This works. > But this does not work: > scp document ap...@ex...:. > Normally this should work. So my question is how can I have scp to > choose the user's home directory automatically? > I tried to change the user home dir both in > /etc/passwd > and in > /usr/chroot/etc/passwd > Neither did not work. |
From: Елизавета О. <1ad...@ma...> - 2015-11-18 05:44:07
|
About my previous email: I guess the problem is that scp does not automatically select the user's home directory. I have to manually specify it. scp document ap...@ex...:homedir/. This works. But this does not work: scp document ap...@ex...: . Normally this should work. So my question is how can I have scp to choose the user's home directory automatically? I tried to change the user home dir both in /etc/passwd and in /usr/chroot/etc/passwd Neither did not work. -- Елизавета Остолоповa |
From: Елизавета О. <1ad...@ma...> - 2015-11-18 05:31:25
|
On Debian 8.2 I created a chroot using the supplied script. cat /etc/rssh.conf ..... user = "apple:011:100010:/usr/chroot" cat /usr/chroot/passwd apple:x:1001:1001::/mnt/apple:/usr/bin/rssh Now when I upload a file using scp, it gives permission denied. When I do this: mkdir /usr/chroot/orange chmod 777 /usr/chroot/orange Then, scp document ap...@ex...:/orange/. it works. It does upload. What is the problem here? Even if I give 777 permissions to /mnt/apple it gives permission denied. -- Елизавета Остолоповa |
From: Derek M. <co...@pi...> - 2015-10-21 01:25:16
|
On Wed, Oct 14, 2015 at 04:11:07PM +0200, Marcel Behlau wrote: > Crosscompile rssh causes a problem at install, since the DESTDIR > isn't used for "install-exec-hook". This patch adds DESTDIR to > "install-exec-hook". There are already patches around that do this... I'm not planning to update the source as this project is essentially unmaintained. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Marcel B. <mar...@el...> - 2015-10-14 14:39:23
|
Crosscompile rssh causes a problem at install, since the DESTDIR isn't used for "install-exec-hook". This patch adds DESTDIR to "install-exec-hook". Best regards, Marcel -- Dipl. Ing (FH) Marcel Behlau (Software Developer) ELFIN GmbH Siegburger Straße 215 50679 Köln Germany Tel: +49 (221) 6778932-0 Fax: +49 (221) 6778932-2 mar...@el... www.elfin.de |
From: Derek M. <co...@pi...> - 2015-04-30 23:44:56
|
On Sat, Apr 18, 2015 at 12:41:46PM -0700, Russ Allbery wrote: > I believe Derek has already said on this list (a few times) that, barring > major security vulnerabilities, he's unlikely to release a new version. Indeed. :) And these days even if, to be honest... I wrote this when I was curious about the problem academically, under-employed, and did not write code for a living. None of those things remain true, and my motivation to bother with this has correspondingly waned rather dramatically. > I don't know if he'd rather someone fork or take over maintenance, > but if someone is willing to be the maintainer and merge various > changes, I recommend saying so explicitly and seeing what Derek > thinks. I don't think, in practical terms, I even still have access to sourceforge, so please feel free to fork. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Russ A. <ea...@ey...> - 2015-04-18 19:57:20
|
Nico Kadel-Garcia <nk...@gm...> writes: > Is our faithful project owner at Sourceforge still on the case? Or is > it time to fork? I have a small stack of updated tools for chroot cage > building at https://github.com/nkadel/rssh-chroot-tools, which I've > used to replace systems with rssh and the hairy old OpenSSH chroot > patches. I believe Derek has already said on this list (a few times) that, barring major security vulnerabilities, he's unlikely to release a new version. I don't know if he'd rather someone fork or take over maintenance, but if someone is willing to be the maintainer and merge various changes, I recommend saying so explicitly and seeing what Derek thinks. (Personally, I'm willing to keep maintaining the Debian packages since I use rssh, but I use only a very limited subset of what it can do, mostly as an additional level of defense in depth around rsync, and I don't use chroots, so the things that people normally care about aren't things I'm likely to work on.) -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Nico Kadel-G. <nk...@gm...> - 2015-04-18 19:20:00
|
On Sat, Apr 18, 2015 at 1:16 PM, Johnson Earls <joh...@or...> wrote: > The rssh Makefiles (Makefile.am and Makefile.in) have one place where they fail to work when installing to a DESTDIR directory: This patch is already in the SRPM's available from EPEL and Fedora, along with other patches for rsync version 3 compatiblity. And the bug is basically 10 years old, and never closed at http://sourceforge.net/p/rssh/bugs/. Is our faithful project owner at Sourceforge still on the case? Or is it time to fork? I have a small stack of updated tools for chroot cage building at https://github.com/nkadel/rssh-chroot-tools, which I've used to replace systems with rssh and the hairy old OpenSSH chroot patches. Nico Kadel-Garcia |
From: Johnson E. <joh...@or...> - 2015-04-18 17:16:30
|
The rssh Makefiles (Makefile.am and Makefile.in) have one place where they fail to work when installing to a DESTDIR directory: diff -r -u rssh-2.3.4/Makefile.am rssh-2.3.4-makefile-DESTDIR-chmod/Makefile.am --- rssh-2.3.4/Makefile.am 2012-11-25 20:01:11.000000000 -0800 +++ rssh-2.3.4-makefile-DESTDIR-chmod/Makefile.am 2015-04-18 10:11:36.209899000 -0700 @@ -19,7 +19,7 @@ $(CC) -c $(DEFS) $(ourdefs) $(AM_CFLAGS) $(CPPFLAGS) $(LDFLAGS) $< install-exec-hook: - chmod u+s $(libexecdir)/rssh_chroot_helper + chmod u+s $(DESTDIR)$(libexecdir)/rssh_chroot_helper rpm: dist rpmbuild -ta --sign $(base).tar.gz diff -r -u rssh-2.3.4/Makefile.in rssh-2.3.4-makefile-DESTDIR-chmod/Makefile.in --- rssh-2.3.4/Makefile.in 2012-11-26 16:19:34.000000000 -0800 +++ rssh-2.3.4-makefile-DESTDIR-chmod/Makefile.in 2015-04-18 10:12:49.099881000 -0700 @@ -730,7 +730,7 @@ $(CC) -c $(DEFS) $(ourdefs) $(AM_CFLAGS) $(CPPFLAGS) $(LDFLAGS) $< install-exec-hook: - chmod u+s $(libexecdir)/rssh_chroot_helper + chmod u+s $(DESTDIR)$(libexecdir)/rssh_chroot_helper rpm: dist rpmbuild -ta --sign $(base).tar.gz This is important for folks who want to package rssh for their installation requirements. -- - Johnson Earls joh...@or... |
From: Russ A. <ea...@ey...> - 2014-08-25 21:01:38
|
James Nylen <jn...@gm...> writes: > With the latest version of Linux Mint Debian Edition, and possibly other > debians, Ah, that explains how you ended up with an odd version. > libnsl needs to be copied to the chroot or scp errors out with the > "unknown user XXX" message. The rssh debian package has a mkchroot.sh > script which works except for this: > /usr/share/doc/rssh/examples/mkchroot.sh > http://nylen.tv/mkchroot.sh > Here's the Debian bug report for this issue: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759270 As mentioned in the bug, I believe this is fixed in 2.3.4-4. There was a typo that caused the mkchroot.sh script to not copy the libnss compat modules (and therefore not libnsl, which is a dependency for them). -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: James N. <jn...@gm...> - 2014-08-25 20:53:49
|
This is to confirm that the issue is fixed in 2.3.4-4. Thanks again for your help! On Mon, Aug 25, 2014 at 3:47 PM, James Nylen <jn...@gm...> wrote: > I see. Please ignore my comment on the bug, I'm retrying with 2.3.4-4 now. > > > On Mon, Aug 25, 2014 at 3:43 PM, Russ Allbery <ea...@ey...> wrote: > >> James Nylen <jn...@gm...> writes: >> >> > With the latest version of Linux Mint Debian Edition, and possibly other >> > debians, >> >> Ah, that explains how you ended up with an odd version. >> >> > libnsl needs to be copied to the chroot or scp errors out with the >> > "unknown user XXX" message. The rssh debian package has a mkchroot.sh >> > script which works except for this: >> >> > /usr/share/doc/rssh/examples/mkchroot.sh >> > http://nylen.tv/mkchroot.sh >> >> > Here's the Debian bug report for this issue: >> >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759270 >> >> As mentioned in the bug, I believe this is fixed in 2.3.4-4. There was a >> typo that caused the mkchroot.sh script to not copy the libnss compat >> modules (and therefore not libnsl, which is a dependency for them). >> >> -- >> Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/ >> > >> > > |
From: James N. <jn...@gm...> - 2014-08-25 20:47:16
|
I see. Please ignore my comment on the bug, I'm retrying with 2.3.4-4 now. On Mon, Aug 25, 2014 at 3:43 PM, Russ Allbery <ea...@ey...> wrote: > James Nylen <jn...@gm...> writes: > > > With the latest version of Linux Mint Debian Edition, and possibly other > > debians, > > Ah, that explains how you ended up with an odd version. > > > libnsl needs to be copied to the chroot or scp errors out with the > > "unknown user XXX" message. The rssh debian package has a mkchroot.sh > > script which works except for this: > > > /usr/share/doc/rssh/examples/mkchroot.sh > > http://nylen.tv/mkchroot.sh > > > Here's the Debian bug report for this issue: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759270 > > As mentioned in the bug, I believe this is fixed in 2.3.4-4. There was a > typo that caused the mkchroot.sh script to not copy the libnss compat > modules (and therefore not libnsl, which is a dependency for them). > > -- > Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> > |
From: James N. <jn...@gm...> - 2014-08-25 19:04:44
|
With the latest version of Linux Mint Debian Edition, and possibly other debians, libnsl needs to be copied to the chroot or scp errors out with the "unknown user XXX" message. The rssh debian package has a mkchroot.sh script which works except for this: /usr/share/doc/rssh/examples/mkchroot.sh http://nylen.tv/mkchroot.sh Here's the Debian bug report for this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759270 Some previous discussion related to libnss* and a similar issue with those libraries: http://sourceforge.net/p/rssh/mailman/message/30590925/ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335384 |
From: Derek M. <co...@pi...> - 2014-08-08 19:22:07
|
On Thu, Aug 07, 2014 at 05:07:14PM +0200, Johan B.W. de Vries wrote: > Since the bug I found was rather simple, I figured I could just post > my solution here, hoping it'd get picket up some day. I promise it won't. This IS NOT a bug, it is working as intended. > The problem is as follows: rsync should not use the -e argument, so > there's a check on that (don't ask me why, but the code says so). It's been discussed several times on the list; feel free to peruse the archives. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Russ A. <ea...@ey...> - 2014-08-07 17:24:35
|
"Johan B.W. de Vries" <jo...@bl...> writes: > I've been trying to set up rssh with rsync 3.0.6, with some difficulty I > made it work. I had to add the --protocol=29 or --protocol=26 command > line argument to rsync, that was not a problem. However, I also had to > modify rssh because all the patches I could find were either out of date > or would not work. Since the bug I found was rather simple, I figured I > could just post my solution here, hoping it'd get picket up some day. The problem that you describe should be fixed by the attached patch, which is applied to the Debian package. The fix you propose could open a security vulnerability since it allows the --rsh flag to be passed to the server. (This hopefully would be okay because the code should require that the --server flag be passed, but it would be better to be safer.) With the attached patch applied, you also won't need to use the --protocol flag, since rssh will recognize -e used for protocol information. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Johan B.W. de V. <jo...@bl...> - 2014-08-07 15:23:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I've been trying to set up rssh with rsync 3.0.6, with some difficulty I made it work. I had to add the --protocol=29 or --protocol=26 command line argument to rsync, that was not a problem. However, I also had to modify rssh because all the patches I could find were either out of date or would not work. Since the bug I found was rather simple, I figured I could just post my solution here, hoping it'd get picket up some day. The problem is as follows: rsync should not use the -e argument, so there's a check on that (don't ask me why, but the code says so). That's why you need to use the protocol argument. However, rsync also passes the --server argument. Since the opt_exist function in util.c doesn't grasp the concept of long arguments, it sees the 'e' in 'server' and claims the -e option has been passed. The fix is rather simple (once you've gotten to this point, after maybe an hour or 3): - ----- begin rss-2.3.4/util.c.diff ----- - --- util.c Thu Aug 07 17:03:50 2014 +++ util.c~ Thu Aug 07 17:02:48 2014 @@ -139,6 +139,10 @@ /* process command line character by character */ if (!(cl[0] == '-')) return FALSE; + + /* Ignore verbose command line arguments */ + if ( (1 < len) && (cl[1] == '-') ) return FALSE; + while ( i < (len) ){ if ( cl[i] == opt ) return TRUE; i++; - ----- begin rss-2.3.4/util.c.diff ----- In this case, the "little over-zealous" really wasn't good enough. Johan de Vries -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT45YiAAoJELlZja9I/jIAO0UH/0p5iv3iTwMKnA9bc/iCh/rc 2TVXd9Scw8qFCTM5kj9dBXGLDICe2Rz1c0e/slLsqbAm9zXUaLGaITnEsxlcDTzy iN9U1xedLStSwsjhCQ3osz6r4QwLFIob/fuoTXagXXvWv7DfwnB5uDiPPN31M0wb CCR4039rZzlS6L5fsE0ThoDrtxu1RN5sythVmYJtkOZG6KAAyZYISwb1sxFBSqPL 6PoBPoMuHK0JapbBBS3cvW8TpuhRDz+bkbHs8cKfutSiHzVviWpFgk0E2OjnWh2U LwUNT0ImOnaNDcEK0CPBbT36ry/Ff3o/kyihg9SboQXaDX+dSgT69V9hbiPgMLE= =w7W1 -----END PGP SIGNATURE----- |
From: Armin S. <arm...@gm...> - 2014-04-21 14:46:23
|
I've found that rssh compiles without problems on Mac OS X (10.7) with a minor modification: as clang considers the symbol log to be defined when compiling rsshconf.c, renaming the integer variable log into log_en resolves the problem. A patch to do so can be found under https://gist.githubusercontent.com/arminsch/9230011/raw/f0c5ed95bbba0be28ce2b5f0d1080de84ec317ab/rsshconf-log-rename.diff It would be nice if the patch could be incorporated into any new maintainance releases. Best regards, Armin |
From: Russ A. <ea...@ey...> - 2014-01-29 21:23:01
|
Petyo Vodenicharov <pi...@gm...> writes: > I've setup rssh to what seemed to be a proper configuration but I > noticed that sftp doesn't go at all via rssh. And therefore doesn't go > in the chroor jail.It just goes via the default sftp module of ssh. > the sshd_config has only this about sftp: > Subsystem sftp internal-sftp When you use subsystem support for sftp, I believe the sshd server never runs a shell or uses the command sent by the client. It instead spawns the sftp server directly or uses the internal built-in sftp implementation. You would therefore have to configure sshd's internal chroot support. rssh can't help with that. I believe you can force the sftp client and sshd server to fall back to running the sftp server command via a shell by disabling the sftp subsystem in the sshd server, at which point those requests should route through rssh again. But I've not tried it. -- Russ Allbery (ea...@ey...) <http://www.eyrie.org/~eagle/> |
From: Petyo V. <pi...@gm...> - 2014-01-29 16:43:01
|
Hello All, I've setup rssh to what seemed to be a proper configuration but I noticed that sftp doesn't go at all via rssh. And therefore doesn't go in the chroor jail.It just goes via the default sftp module of ssh. rssh.conf: logfacility = LOG_USER allowscp allowsftp umask = 022 chrootpath = /export user=user:007:00011:/export/user user:x:2004:2004:no shell user:/export/user:/usr/bin/rssh /var/log/messages contains this upon creating a scp connection: Jan 29 17:15:36 server01 rssh[18356]: setting log facility to LOG_USER Jan 29 17:15:36 server01 rssh[18356]: allowing scp to all users Jan 29 17:15:36 server01 rssh[18356]: allowing sftp to all users Jan 29 17:15:36 server01 rssh[18356]: setting umask to 022 Jan 29 17:15:36 server01 rssh[18356]: chrooting all users to /chrootpl Jan 29 17:15:36 server01 rssh[18356]: line 53: configuring user user Jan 29 17:15:36 server01 rssh[18356]: setting user's umask to 07 Jan 29 17:15:36 server01 rssh[18356]: allowing scp to user user Jan 29 17:15:36 server01 rssh[18356]: allowing sftp to user user Jan 29 17:15:36 server01 rssh[18356]: chrooting user to /export/user Jan 29 17:15:36 server01 rssh[18356]: chroot cmd line: /usr/libexec/rssh_chroot_helper 1 "scp -t in/" but nothing when sftp is connecting. the sshd_config has only this about sftp: Subsystem sftp internal-sftp when I have a match rule in the sftp the scp doesn't work: Match group noshell ChrootDirectory %h X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp so this is no commented out. Has anyone else also noticed this? Does anyone have any pointers? -- Best Regards, Petyo Vodenicharov |
From: Derek M. <co...@pi...> - 2014-01-20 00:45:10
|
On Wed, Jan 15, 2014 at 11:20:02AM +0100, Tomasz Chmielewski wrote: > I was trying to use rssh to restrict regular users - it works like > charm. > > Then, I've tried to restrict users with UID=0 - unfortunately, chroot > doesn't seem to work in that case. > > Consider the following users in /etc/passwd: > > root:x:0:0:root:/root:/bin/bash > some@user:x:0:0::/mnt/storage/some@user:/usr/bin/rssh I would really need to re-read the source to guess what impact this would have, but this is in general very bad practice, and by and large, won't work the way you hope it will. Reliably chrooting any user whose UID is 0 CAN NOT WORK if they have full shell access. This is the primary purpose of this feature in RSSH; i.e. if your restricted user is somehow able to bypass the protection provided by RSSH and get a shell, the idea is that putting them in a chroot jail limits the damage they can do. However, if the user's UID is 0, they can ALWAYS break out of any chroot jail so long as they can a) change directory (anywhere) and b) find a way to call the chroot system call (e.g. by running the chroot program, or by executing a custom-compiled program they've uploaded within the jail). I suspect that what's going on here is that getpwuid(), which will simply read user entries (in your password file, NIS database, or whatever authentication your system is configured to use) until it finds the FIRST entry which matches that UID, is finding the entry for root, and thus it is using whatever permissions root would have (or possibly bypassing control entirely). Having multiple users with the same UID, while possible, is basically horribly broken, and can result in all kinds of unexpected behavior. The security consequenses of this are hard to predict, and when the UID in question is 0, you're just begging for serious problems. In short, this is unsupported by RSSH, and behavior may vary based upon exactly how your system is configured. You should also generally assume that any such user on your system can do anything, and most especially expect that they can override whatever security restrictions you THINK you've imposed upon them. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |