rssh-discuss Mailing List for rssh (Page 4)
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: Tomasz C. <ma...@wp...> - 2014-01-19 21:44:41
|
On Sun, 19 Jan 2014 07:35:05 -0800 Ben Walton <bdw...@gm...> wrote: > > I'm getting chroot for some@user when the UID is different than 0. > > If the UID for some@user is set to 0, I'm no longer getting the > > chroot and I'm able to browse the whole server. > > What do you expect to achieve by chrooting a uid=0 account? With > uid=0, it is easy to step out of a chroot...chroot is not a security > mechanism. My usage scenario is as follows: - user rsyncs (or uses sftp) data to a chrooted environment, - as uid=0, the user is able to keep uids/gids exactly in sync with the origin server. I'm aware that it's trivial to get out of chroot if you have a root shell, but my impression was that rssh was the tool to prevent it. Are there any known security issues with rssh which would allow a chrooted user with uid=0 to bypass chroot? I assume the following: - allowscp, allowsftp, allowrsync options enabled - chroot environment read only, except the area where the users puts new data -- Tomasz Chmielewski http://wpkg.org |
From: Tomasz C. <ma...@wp...> - 2014-01-15 10:20:12
|
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'm getting chroot for some@user when the UID is different than 0. If the UID for some@user is set to 0, I'm no longer getting the chroot and I'm able to browse the whole server. Is it expected behaviour? -- Tomasz Chmielewski http://wpkg.org |
From: William K. <po...@ya...> - 2013-11-02 10:52:56
|
Hi all, I'm running a test setup on CentOS 6.4 with rssh 2.3.3-2 What I try to archive is setting up two scp/sftp account with separated filesystems and chroot environment. (Let me know there's another way to isolated what two ID can see) I setup ID ftp1 successfully an login as expected. Then clone ftp1 to ftp2. however it is just not working with chroot. Any suggestion? /etc/passwd: ftp1:x:1026:999::/chroot/ftp1/ftp1:/usr/bin/rssh ftp2:x:1027:999::/chroot/ftp2/ftp2:/usr/bin/rssh /etc/rssh.conf logfacility = LOG_USER allowscp allowsftp umask = 022 user=ftp1:022:00011:/chroot/ftp1 user=ftp2:022:00011:/chroot/ftp2 Filesystems: # pwd /chroot # ls -l drwx------ 10 ftp1 fmguest 4096 Nov 2 05:34 ftp1 drwx------ 11 ftp2 fmguest 4096 Nov 2 05:31 ftp2 For ftp1 ========== # cat /chroot/ftp1/etc/passwd ftp1:x:1026:999::/ftp1:/usr/bin/rssh For ftp2 ========== # cat /chroot/ftp2/etc/passwd ftp2:x:1027:999::/ftp2:/usr/bin/rssh Test ========= # sftp ftp1@testhost Connecting to testhost.. ftp1@testhost's password: sftp> pwd Remote working directory: /ftp1 sftp> exit # sftp ftp2@testhost Connecting to testhost... ftp2@testhost's password: Connection closed |
From: Derek M. <co...@pi...> - 2013-10-02 07:01:20
|
Thanks Russ. I should really put up a FAQ about this, so you don't have to keep answering this question... =8^) [Though, if people would just take a moment to actually search for the answer...] http://lmgtfy.com/?q=rssh+rsync+3 -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D On Tue, Sep 24, 2013 at 12:46:21PM -0700, Russ Allbery wrote: > Andrew Daviel <ad...@tr...> writes: > > > We have a server with rssh-2.2.3 on CentOS 3, and tried connecting with > > rsync-3.0.6 from CentOS 5. > > > I get "insecure -e option not allowed". > > When I look a the source for rsync, I find it's adding "-e.s" for some > > reason but I can fix that by using --protocol=26. > > > I tried building the current version of rssh (2.3.4-1) thinking that maybe > > the problem was fixed. But it's actually worse. > > > I don't know why rsync is sending "--sender" etc., but it's the standard > > RedHat version of rsync. I'm guessing that rssh is not parsing long options > > properly and is just finding 'e' in --server. > > > Seeing as rsync is one of the documented commands that works with rssh, > > I'm wondering what's going on. > > I see that Sourceforge has completely broken their mailing list archives > so that you can't retrieve the content of previous list messages or I > would point you at the previous discussion of this. > > You need patches in order to work with the latest rsync. They reused the > -e option in a very unfortunate way to specify protocol information, and > it's quite tricky to ensure that the running command is still secure. > > Debian (and I believe some others) are using the attached, which is > against 2.3.4. (I would point you to the Debian patch tracker, but it's > down at the moment; the link at: > > http://patch-tracker.debian.org/package/rssh/2.3.3-6 > > has the patch set against 2.3.3, which includes the security fix in 2.3.4, > but that's not as clean as the patches based on 2.3.4 directly.) > > -- > Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> > > From: Russ Allbery <rr...@st...> > Subject: [PATCH] Handle the rsync v3 -e option for protocol information > > As of rsync 3, rsync reused the -e option to pass protocol information > from the client to the server. We therefore cannot reject all -e > options to rsync, only ones not sent with --server or containing > something other than protocol information as an argument. > > Also scan the rsync command line for any --rsh option and reject it as > well. This replaces and improves the upstream strategy for rejecting > that command-line option, taking advantage of the parsing added to > check the -e option. > > Based on work by Robert Hardy. > > Debian Bug#471803 > > Signed-off-by: Russ Allbery <rr...@st...> > > --- > util.c | 80 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++------- > 1 file changed, 72 insertions(+), 8 deletions(-) > > diff --git a/util.c b/util.c > index f98d2bc..a257b06 100644 > --- a/util.c > +++ b/util.c > @@ -56,6 +56,7 @@ > #ifdef HAVE_LIBGEN_H > #include <libgen.h> > #endif /* HAVE_LIBGEN_H */ > +#include <regex.h> > > /* LOCAL INCLUDES */ > #include "pathnames.h" > @@ -198,6 +199,73 @@ bool check_command( char *cl, ShellOptions_t *opts, char *cmd, int cmdflag ) > > > /* > + * rsync_e_okay() - take the command line passed to rssh and look for an -e > + * option. If one is found, make sure --server is provided > + * and the option contains only the protocol information. > + * Also check for and reject any --rsh option. Returns FALSE > + * if the command line should not be allowed, TRUE if it is > + * okay. > + */ > +static int rsync_e_okay( char **vec ) > +{ > + regex_t re; > + int server = FALSE; > + int e_found = FALSE; > + > + /* > + * rsync will send -e, followed by either just "." (meaning no special > + * protocol) or "N.N" (meaning a pre-release protocol version), > + * followed by some number of alphabetic flags indicating various > + * supported options. There may be other options between - and the e, > + * but -e will always be the last option in the string. A typical > + * option passed by the client is "-ltpre.iL". > + * > + * Note that if --server is given, this should never be parsed as a > + * shell, but we'll tightly verify it anyway, just in case. > + * > + * This regex matches the acceptable flags containing -e, so if it > + * does not match, the command line should be rejected. > + */ > + static const char pattern[] > + = "^-[a-df-zA-Z]*e[0-9]*\\.[0-9]*[a-zA-Z]*$"; > + > + /* > + * Only recognize --server if it's the first option. rsync itself > + * always passes it that way, and if it's not the first argument, it > + * could be hidden from the server as an argument to some other > + * option. > + */ > + if ( vec && vec[0] && vec[1] && strcmp(vec[1], "--server") == 0 ){ > + server = TRUE; > + } > + > + /* Check the remaining options for -e or --rsh. */ > + if ( regcomp(&re, pattern, REG_EXTENDED | REG_NOSUB) != 0 ){ > + return FALSE; > + } > + while (vec && *vec){ > + if ( strcmp(*vec, "--") == 0 ) break; > + if ( strcmp(*vec, "--rsh") == 0 > + || strncmp(*vec, "--rsh=", strlen("--rsh=")) == 0 ){ > + regfree(&re); > + return FALSE; > + } > + if ( strncmp(*vec, "--", 2) != 0 && opt_exist(*vec, 'e') ){ > + e_found = TRUE; > + if ( regexec(&re, *vec, 0, NULL, 0) != 0 ){ > + regfree(&re); > + return FALSE; > + } > + } > + vec++; > + } > + regfree(&re); > + if ( e_found && !server ) return FALSE; > + return TRUE; > +} > + > + > +/* > * check_command_line() - take the command line passed to rssh, and verify > * that the specified command is one the user is > * allowed to run and validate the arguments. Return the > @@ -230,14 +298,10 @@ char *check_command_line( char **cl, ShellOptions_t *opts ) > > if ( check_command(*cl, opts, PATH_RSYNC, RSSH_ALLOW_RSYNC) ){ > /* filter -e option */ > - if ( opt_filter(cl, 'e') ) return NULL; > - while (cl && *cl){ > - if ( strstr(*cl, "--rsh" ) ){ > - fprintf(stderr, "\ninsecure --rsh= not allowed."); > - log_msg("insecure --rsh option in rsync command line!"); > - return NULL; > - } > - cl++; > + if ( !rsync_e_okay(cl) ){ > + fprintf(stderr, "\ninsecure -e or --rsh option not allowed."); > + log_msg("insecure -e or --rsh option in rsync command line!"); > + return NULL; > } > return PATH_RSYNC; > } > -- > tg: (f8b36e2..) fixes/rsync-protocol (depends on: upstream) > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > rssh-discuss mailing list > rss...@li... > https://lists.sourceforge.net/lists/listinfo/rssh-discuss |
From: Andrew D. <ad...@tr...> - 2013-09-24 20:51:21
|
On Tue, 24 Sep 2013, Russ Allbery wrote: > I see that Sourceforge has completely broken their mailing list archives > so that you can't retrieve the content of previous list messages or I > would point you at the previous discussion of this. > > You need patches in order to work with the latest rsync. They reused the > -e option in a very unfortunate way to specify protocol information, and > it's quite tricky to ensure that the running command is still secure. Thank you, that works nicely. I added it as a patch in the specfile and built an RPM. I see now in the archives (as you say, sparse and hard to search) that you wrote much the same in August. And back in 2011. I also found Derek's post on Dec 04 2012 saying that he won't support the rsync patch, but that most vendors have it in their RPM packages. Yum is broken on our old CentOS 3 machine so the easy way didn't work, but it's in EPEL for Centos5 and 6. -- Andrew Daviel, TRIUMF, Canada Tel. +1 (604) 222-7376 (Pacific Time) |
From: Russ A. <rr...@st...> - 2013-09-24 19:46:30
|
Andrew Daviel <ad...@tr...> writes: > We have a server with rssh-2.2.3 on CentOS 3, and tried connecting with > rsync-3.0.6 from CentOS 5. > I get "insecure -e option not allowed". > When I look a the source for rsync, I find it's adding "-e.s" for some > reason but I can fix that by using --protocol=26. > I tried building the current version of rssh (2.3.4-1) thinking that maybe > the problem was fixed. But it's actually worse. > I don't know why rsync is sending "--sender" etc., but it's the standard > RedHat version of rsync. I'm guessing that rssh is not parsing long options > properly and is just finding 'e' in --server. > Seeing as rsync is one of the documented commands that works with rssh, > I'm wondering what's going on. I see that Sourceforge has completely broken their mailing list archives so that you can't retrieve the content of previous list messages or I would point you at the previous discussion of this. You need patches in order to work with the latest rsync. They reused the -e option in a very unfortunate way to specify protocol information, and it's quite tricky to ensure that the running command is still secure. Debian (and I believe some others) are using the attached, which is against 2.3.4. (I would point you to the Debian patch tracker, but it's down at the moment; the link at: http://patch-tracker.debian.org/package/rssh/2.3.3-6 has the patch set against 2.3.3, which includes the security fix in 2.3.4, but that's not as clean as the patches based on 2.3.4 directly.) -- Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> |
From: Andrew D. <ad...@tr...> - 2013-09-24 19:38:00
|
We have a server with rssh-2.2.3 on CentOS 3, and tried connecting with rsync-3.0.6 from CentOS 5. I get "insecure -e option not allowed". When I look a the source for rsync, I find it's adding "-e.s" for some reason but I can fix that by using --protocol=26. I tried building the current version of rssh (2.3.4-1) thinking that maybe the problem was fixed. But it's actually worse. I don't know why rsync is sending "--sender" etc., but it's the standard RedHat version of rsync. I'm guessing that rssh is not parsing long options properly and is just finding 'e' in --server. Seeing as rsync is one of the documented commands that works with rssh, I'm wondering what's going on. $ rsync -vv andrew@myserver:public_html/two/try2.html . opening connection using: ssh -l andrew trshare rsync --server --sender -vve.s . public_html/two/try2.html illegal insecure e option This account is restricted by rssh. Allowed commands: scp sftp rsync $ rsync -vv --protocol=26 andrew@myserver:public_html/two/try2.html . opening connection using: ssh -l andrew trshare rsync --server --sender -vv . public_html/two/try2.html illegal insecure e option -- Andrew Daviel, TRIUMF, Canada Tel. +1 (604) 222-7376 (Pacific Time) |
From: Russ A. <rr...@st...> - 2013-08-15 18:45:50
|
Scott Ehas <sco...@gi...> writes: > I am unable to find any documentation on the Rsync functions for RSSH. > Every time I try to Rsync with the RSSH I get a "insecure -e option now > allowed". I was wondering if you can spot the problem and review the > output below. Please let me know if you can provide any help. You need patches in order to work with the latest rsync. They reused the -e option in a very unfortunate way to specify protocol information, and it's quite tricky to ensure that the running command is still secure. Debian (and I believe some others) are using the attached, which is against 2.3.4. (I would point you to the Debian patch tracker, but it's down at the moment; the link at: http://patch-tracker.debian.org/package/rssh/2.3.3-6 has the patch set against 2.3.3, which includes the security fix in 2.3.4, but that's not as clean as the patches based on 2.3.4 directly.) -- Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> |
From: Scott E. <sco...@gi...> - 2013-08-15 16:32:49
|
Hello, I am unable to find any documentation on the Rsync functions for RSSH. Every time I try to Rsync with the RSSH I get a "insecure -e option now allowed". I was wondering if you can spot the problem and review the output below. Please let me know if you can provide any help. 1. scott /home/scott rsync -Pav "ssh" scott@X.X.X.X:/home/scott 2. The authenticity of host 'X.X.X.X (X.X.X.X)' can't be established. 3. RSA key fingerprint is . 4. Are you sure you want to continue connecting (yes/no)? yes 5. Warning: Permanently added 'X.X.X.X' (RSA) to the list of known hosts. 6. scott@X.X.X.X's password: 7. 8. insecure -e option not allowed. 9. This account is restricted by rssh. 10. Allowed commands: scp sftp rdist rsync 11. 12. If you believe this is in error, please contact your system administrator. 13. 14. rsync: connection unexpectedly closed (0 bytes received so far) [sender] 15. rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9] 16. 17. --------------------------------------------------------------------------------------- 18. /var/log/messages -- 19. 20. Aug 15 10:50:42 FTPBeast-Dev rssh[2081]: allowing scp to all users 21. Aug 15 10:50:42 FTPBeast-Dev rssh[2081]: allowing sftp to all users 22. Aug 15 10:50:42 FTPBeast-Dev rssh[2081]: allowing rdist to all users 23. Aug 15 10:50:42 FTPBeast-Dev rssh[2081]: allowing rsync to all users 24. Aug 15 10:50:42 FTPBeast-Dev rssh[2081]: setting umask to 022 25. Aug 15 10:50:42 FTPBeast-Dev rssh[2081]: insecure -e option in rdist command line! 26. Aug 15 10:50:42 FTPBeast-Dev rssh[2081]: user scott attempted to execute forbidden commands 27. Aug 15 10:50:42 FTPBeast-Dev rssh[2081]: command: rsync --server -vlogDtpre.iLsf --partial . /home/scott 28. 29. ---------------------------------------------------------------------------------------- 30. /etc/rssh.conf 31. logfacility = LOG_USER 32. allowscp 33. allowsftp 34. allowrdist 35. allowrsync |
From: Derek M. <co...@pi...> - 2013-07-17 21:01:23
|
On Wed, Jul 17, 2013 at 02:47:46PM -0400, John Robison wrote: [...] > I uncomment chrootpath and set it to what should be a valid chroot path, > sftp logins will terminate immediately after I enter the SFTP password. > > If you know how to solve the above problem, great, but I'm more interested > in getting some useful logs that will help me troubleshoot this problem. Your problem (or rather, both of them) is that your jail is not set up correctly. You can't get the logs once you're chrooted until the chroot jail is set up properly. The documentation that comes with rssh goes to great detail to describe how to do this properly. The relevant documentation is in the tarball, if you installed from source, or usually installed in /usr/share/doc/rssh or some similar such distribution-dependent path, and is in the file called CHROOT. Some distributions also put a system-dependent script there, to help you set up a chroot jail. Alas, the process IS system dependent, which is why rssh doesn't do this for you. If you've read the docs and you still can't figure out how to make it work, the list archives are full of solutions to this problem; in fact it is very nearly the only thing that anyone ever posts about. One of them is bound to help you. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: John R. <joh...@hm...> - 2013-07-17 19:17:56
|
Hello, I am trying to get chroot to work with rssh for sftp. sftp works fine for users who use rssh as their shell, but only when chroot is not involved. If I uncomment chrootpath and set it to what should be a valid chroot path, sftp logins will terminate immediately after I enter the SFTP password. If you know how to solve the above problem, great, but I'm more interested in getting some useful logs that will help me troubleshoot this problem. The only log entry that goes to the syslog is this one, which doesn't seem very interesting: rssh[22313]: chroot cmd line: /usr/lib/rssh/rssh_chroot_helper 2 "/usr/lib/openssh/sftp-server" My question is, how do I get rssh to produce a useful error here? Thanks.! And here's some additional logging that I have, although I don't personally see much there. rssh -v rssh 2.3.4 And here's some additional logging that I have, although I don't personally see much value in either. auth.log shows that the password was accepted, but that's about it. Jul 17 14:23:41 myserver sshd[22611]: Accepted password for TEST_SFTP from 10.100.11.3 port 53593 ssh2 Jul 17 14:23:41 myserver sshd[22611]: pam_unix(sshd:session): session opened for user TEST_SFTP by (uid=0) Jul 17 14:23:42 myserver sshd[22755]: subsystem request for sftp by user TEST_SFTP Jul 17 14:23:42 myserver sshd[22755]: Received disconnect from 10.100.11.3: 11: disconnected by user Jul 17 14:23:42 myserver sshd[22611]: pam_unix(sshd:session): session closed for user TEST_SFTP And here is the output of sftp -v myserver, on the client side. sftp -v TEST_SFTP@ironman OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to ironman [10.100.10.116] port 22. debug1: Connection established. debug1: identity file /home/jwr/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/jwr/.ssh/id_rsa-cert type -1 debug1: identity file /home/jwr/.ssh/id_dsa type -1 debug1: identity file /home/jwr/.ssh/id_dsa-cert type -1 debug1: identity file /home/jwr/.ssh/id_ecdsa type -1 debug1: identity file /home/jwr/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 73:4d:12:ab:20:0a:59:0d:e7:6a:1d:41:71:50:eb:7c debug1: Host 'ironman' is known and matches the ECDSA host key. debug1: Found key in /home/jwr/.ssh/known_hosts:88 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/jwr/.ssh/id_rsa debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/jwr/.ssh/id_dsa debug1: Trying private key: /home/jwr/.ssh/id_ecdsa debug1: Next authentication method: password TEST_SFTP@ironman's password: debug1: Authentication succeeded (password). Authenticated to ironman ([10.100.10.116]:22). debug1: channel 0: new [client-session] debug1: Requesting no-...@op... debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug1: Sending subsystem: sftp debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eo...@op... reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK Transferred: sent 2232, received 1648 bytes, in 0.4 seconds Bytes per second: sent 6158.0, received 4546.7 debug1: Exit status 1 Connection closed |
From: Gary B. <rss...@ad...> - 2013-03-12 17:29:16
|
On Tue, Mar 12, 2013 at 10:23:45AM -0700, Russ Allbery wrote: > Gary Barnes <rss...@ad...> writes: > > Yes. > > > "aptitude install rssh" installed version 2.3.3-1 on Ubuntu 12.04.2 > > LTS. Doing the same on an Ubuntu 12.10 server installed 2.3.3-5. > > > From your description, the exact problem I saw is fixed in a later > > version, which is all I hoped to achieve by my post, so all's good. > > > It seems my problem was due to Ubuntu not keeping up with releases of > > rssh. > > Oh, I see my mistake. I thought 12.04 was quantal. It's precise, which > indeed had too old of a version (by just one revision). It's not Ubuntu's > fault; they released with the latest version that was available from > Debian at the time. Debian was much slower than Ubuntu to switch to > multiarch, and then I was a bit slow to adapt the package. Yes, checking the mkchroot.sh script on the Ubuntu 12.10 server I just installed it on, the mkchroot.sh script does include the fix (in 2.3.3-5). Gaz |
From: Russ A. <rr...@st...> - 2013-03-12 17:23:55
|
Gary Barnes <rss...@ad...> writes: > Yes. > "aptitude install rssh" installed version 2.3.3-1 on Ubuntu 12.04.2 > LTS. Doing the same on an Ubuntu 12.10 server installed 2.3.3-5. > From your description, the exact problem I saw is fixed in a later > version, which is all I hoped to achieve by my post, so all's good. > It seems my problem was due to Ubuntu not keeping up with releases of > rssh. Oh, I see my mistake. I thought 12.04 was quantal. It's precise, which indeed had too old of a version (by just one revision). It's not Ubuntu's fault; they released with the latest version that was available from Debian at the time. Debian was much slower than Ubuntu to switch to multiarch, and then I was a bit slow to adapt the package. -- Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> |
From: Gary B. <rss...@ad...> - 2013-03-12 17:08:21
|
On Tue, Mar 12, 2013 at 09:38:37AM -0700, Russ Allbery wrote: > Gary Barnes <rss...@ad...> writes: > > I'm not entirely sure what "installed from packages" refers to -- did you > install the rssh package in Ubuntu? Yes. "aptitude install rssh" installed version 2.3.3-1 on Ubuntu 12.04.2 LTS. Doing the same on an Ubuntu 12.10 server installed 2.3.3-5. >From your description, the exact problem I saw is fixed in a later version, which is all I hoped to achieve by my post, so all's good. It seems my problem was due to Ubuntu not keeping up with releases of rssh. Gaz |
From: Russ A. <rr...@st...> - 2013-03-12 16:38:49
|
Gary Barnes <rss...@ad...> writes: > I installed rssh from packages, and used the mkchroot.sh script to create a > chroot jail for a user. The script threw up errors, and when I tried to > connect, I got the "Connection closed" message. > The FAQ says: > "However it seems that on recent Linux distros, the script is missing > something important, and I haven't yet figured out what that is... If you > are able to identify it, please post to the mailing list to let me (and > everyone else) know." > So, to get it to work, I altered the lines that referred to libnss file to > change /lib/ to /lib/x86_64-linux-gnu/ I'm not entirely sure what "installed from packages" refers to -- did you install the rssh package in Ubuntu? The mkchroot.sh script that is shipped with that package (in /usr/share/doc/rssh) should already handle this case correctly via the following: # On Debian with multiarch, the libnss files are in /lib/<triplet>, where # <triplet> is the relevant architecture triplet. Just copy everything # that's installed, since we're not sure which ones we'll need. echo "copying name service resolution libraries..." if [ -n "$(find /lib -maxdepth 1 -name 'libnss*_' -print -quit)" ] ; then tar -cf - /lib/libnss_compat* /lib/libnss*_files* \ | tar -C "$jail_dir" -xvf - | sed 's/^/\t/' else tar -cf - /lib/*/libnss_compat* /lib/*/libnss*_files* \ | tar -C "$jail_dir" -xvf - | sed 's/^/\t/' fi -- Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> |
From: Gary B. <rss...@ad...> - 2013-03-12 15:52:10
|
I installed rssh from packages, and used the mkchroot.sh script to create a chroot jail for a user. The script threw up errors, and when I tried to connect, I got the "Connection closed" message. The FAQ says: "However it seems that on recent Linux distros, the script is missing something important, and I haven't yet figured out what that is... If you are able to identify it, please post to the mailing list to let me (and everyone else) know." So, to get it to work, I altered the lines that referred to libnss file to change /lib/ to /lib/x86_64-linux-gnu/ Here's a simple diff: $ diff mkchroot.sh.orig mkchroot.sh 151c151 < /lib/libnss_compat* /lib/libnss_files*; do --- > /lib/x86_64-linux-gnu/libnss_compat* /lib/x86_64-linux-gnu/libnss_files*; do 164c164 < tar -cf - /lib/libnss_compat* /lib/libnss_files* | tar -C "$jail_dir" -xvf - |sed 's/^/\t/' --- > tar -cf - /lib/x86_64-linux-gnu/libnss_compat* /lib/x86_64-linux-gnu/libnss_files* | tar -C "$jail_dir" -xvf - |sed 's/^/\t/' Gaz |
From: Terry <td...@gm...> - 2012-12-20 01:43:03
|
On Wed, Dec 19, 2012 at 7:31 PM, Derek Martin <co...@pi...> wrote: > On Wed, Dec 19, 2012 at 11:22:51AM -0600, Terry wrote: >> We just upgraded to 2.3.3 (via EPEL on RHEL 6). After the upgrade, >> our users get this when trying to simply scp in: >> /usr/bin/rssh: Permission denied > > This usually means that the program does not have execute permissions. > In the case of a shell (such as rssh), however, it could also mean > that the program that the shell is trying to execute does not have > execute permissions. So look at the file permissions on rssh and on > the scp binary, and make sure they have appropriate permissions for > the users/groups who will be running them. At any rate, this really > isn't an rssh problem per se. > >> The users are all part of an "sftp" group that has this in /etc/security/access: >> +:sftp:ALL >> >> I am not sure how to further debug this. Anyone have some ideas? > > It could also be that this is somehow failing. You could debug by > temporarily changing a user's shell to bash and running id after they > log in. > > Also look at the system logs (generally /var/log/messages) or wherever > you have rssh configured to log. The USER log facility is (by > default) configured to log to a different log file than the AUTH > facility. There may be more info there. > > -- > Derek D. Martin > http://www.pizzashack.org/ > GPG Key ID: 0x81CFE75D > You're right. Not an rssh issue. The binary had 750 permissions on it with root:rsshusers and the users were not in this group. Apparently the upgraded package tightened these permissions. Thank you for the nudge. |
From: Derek M. <co...@pi...> - 2012-12-20 01:31:33
|
On Wed, Dec 19, 2012 at 11:22:51AM -0600, Terry wrote: > We just upgraded to 2.3.3 (via EPEL on RHEL 6). After the upgrade, > our users get this when trying to simply scp in: > /usr/bin/rssh: Permission denied This usually means that the program does not have execute permissions. In the case of a shell (such as rssh), however, it could also mean that the program that the shell is trying to execute does not have execute permissions. So look at the file permissions on rssh and on the scp binary, and make sure they have appropriate permissions for the users/groups who will be running them. At any rate, this really isn't an rssh problem per se. > The users are all part of an "sftp" group that has this in /etc/security/access: > +:sftp:ALL > > I am not sure how to further debug this. Anyone have some ideas? It could also be that this is somehow failing. You could debug by temporarily changing a user's shell to bash and running id after they log in. Also look at the system logs (generally /var/log/messages) or wherever you have rssh configured to log. The USER log facility is (by default) configured to log to a different log file than the AUTH facility. There may be more info there. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Terry <td...@gm...> - 2012-12-19 17:22:59
|
We just upgraded to 2.3.3 (via EPEL on RHEL 6). After the upgrade, our users get this when trying to simply scp in: /usr/bin/rssh: Permission denied lost connection The security logs show this: Dec 19 11:20:38 server01 sshd[19499]: Accepted keyboard-interactive/pam for tdtest from ::1 port 42920 ssh2 Dec 19 11:20:38 serverws01 sshd[19499]: pam_unix(sshd:session): session opened for user tdtest by (uid=0) Dec 19 11:20:38 server01 sshd[19509]: Received disconnect from ::1: 11: disconnected by user Dec 19 11:20:38 server01 sshd[19499]: pam_unix(sshd:session): session closed for user tdtest The only thing not commented out in rssh.conf is this: logfacility = LOG_USER allowscp allowsftp allowcvs allowrdist allowrsync umask = 022 The users are all part of an "sftp" group that has this in /etc/security/access: +:sftp:ALL I am not sure how to further debug this. Anyone have some ideas? Thanks! |
From: Derek M. <co...@pi...> - 2012-12-04 22:42:53
|
On Tue, Dec 04, 2012 at 06:23:38PM +0000, Chris Bull wrote: > having been suitably and correctly chastised off list for the poor > practice I displayed in my previous post, On the subject of chastisement... It's generally considered bad netiquette to post HTML to mailing lists. I personally don't care, but there are a variety of perfectly valid reasons why some people do. FYI. > Approach run on CENTOS 6.3 as a NON ROOT user. rpmbuild will not > build directly from the SPEC file included in the tar.gz file :-( Note that I no longer build RPMs, and the spec file was mainly for my benefit. You'll notice there's a make target for it also, in Makefile.am. But if you look at it you'll quickly realize that it won't work for anyone but me, as it signs the RPM with my private key. The reason I don't build RPMs is because all of the major distros now include rssh in their various repositories: $ egrep "ID|RELEASE" /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.04 $ apt-cache search rssh clusterssh - administer multiple ssh or rsh shells simultaneously rssh - Restricted shell allowing scp, sftp, cvs, svn, rsync or rdist Fedora has one too (though it may require you to enable one of their "alternative" repositories, I can't speak to that, don't have a fedora install handy at work), and I believe RHEL 6 and later do as well, etc... YMMV based on your particular distro. So point is, for what it's worth, maintenance of the spec file is discontinued. For the most part you should rely on what your vendor packages. Though it is worth noting that most of those have taken the rsync v3 patch, which I never will. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
From: Chris B. <chr...@gm...> - 2012-12-04 18:23:47
|
All, having been suitably and correctly chastised off list for the poor practice I displayed in my previous post, Here is an improved approach. Approach run on CENTOS 6.3 as a NON ROOT user. rpmbuild will not build directly from the SPEC file included in the tar.gz file :-( The issue appears to be wholly limited to the handling of the RSSH.conf file. The spec file needs to be patched to work correctly, the below is the recommended patch: $ diff -u BUILD/rssh-2.3.4/rssh.spec SPECS/rssh.spec --- BUILD/rssh-2.3.4/rssh.spec 2012-12-03 18:08:34.245272000 -0500 +++ SPECS/rssh.spec 2012-12-03 18:08:22.560241000 -0500 @@ -32,11 +32,13 @@ %install %{__rm} -rf %{buildroot} %makeinstall +%{__mv} %{buildroot}/%{_sysconfdir}/rssh.conf.default %{buildroot}/%{_sysconfdir}/rssh.conf %files %defattr(644, root, root, 0755) %doc AUTHORS ChangeLog CHROOT COPYING README SECURITY TODO conf_convert.sh mkchroot.sh %doc %{_mandir}/man?/* +%doc rssh.conf.default %config(noreplace) %{_sysconfdir}/rssh.conf %attr(755, root, root) %{_bindir}/rssh %attr(4755, root, root) %{_libexecdir}/rssh_chroot_helper either replace the spec file within the tar.gz file with the patched version and run rpmbuild -ta (or tb) <updated tar.gz file> or place an unmodified version of the tar.gz file within ~/rpmbuild/SOURCES and run rpmbuild -bb (or ba if you want an SRPM) <patched spec file> Commentary on issues with my previous instructions: (Thanks to Nico Kade-Garcia) Not good. This leaves a "noreplace" configuration file of rssh.conf.default, which is completely useless. This change also stores a copy of the default rssh.conf file in /usr/share/doc, which is reasonable. Regards Chris |
From: Chris B. <chr...@gm...> - 2012-12-03 18:02:21
|
All, It may be of some interest to anyone trying to roll their own RPM of this application: to build an RPM of rssh follow the following steps (this was completed on a CENTOS 6.3 server with the development workstation package set) assuming running as root. extract the tar.gz file. (into ~/ is fine) mkdir -p /root/rpmbuild/SOURCES cp the tar.gz file into the above directory (not extracted) cd into your extracted directory. edit the rssh.spec file for the following line: Replace: %config(noreplace) ${_sysconfdir}/rssh.conf with: %config(noreplace) ${_sysconfdir}/rssh.conf.default then type rpmbuild -bb rssh.spec your new RPMs will now be found in: /root/rpmbuild/RPMS/<arch>/ Hope this is of some assistance to someone....... Chris |
From: Russ A. <rr...@st...> - 2012-11-28 20:19:30
|
Nico Kadel-Garcia <nk...@gm...> writes: > Any chance I can talk you into submitting an update request at > redhat.bugizlla.com? As the author of rssh, I suspect they'll take > your update suggestion a lot more seriously than mine. The security issue was coordinated with the Red Hat security team, so I suspect it's already on their radar. -- Russ Allbery (rr...@st...) <http://www.eyrie.org/~eagle/> |
From: Nico Kadel-G. <nk...@gm...> - 2012-11-28 13:11:52
|
On Tue, Nov 27, 2012 at 6:59 PM, Derek Martin <co...@pi...> wrote: > All, > > Today I released rssh-2.3.4, which fixes an old issue, and a new > issue: > Lastly, since the vendors are providing their own packages, and I'm no > longer set up to build RPMs, I am no longer providing rssh in RPM > form. Please be sure to update rssh to v2.3.4, either by downloading > and compiling from the website, or by updating your vendor's packages. > > http://www.pizzashack.org/rssh/downloads.shtml Any chance I can talk you into submitting an update request at redhat.bugizlla.com? As the author of rssh, I suspect they'll take your update suggestion a lot more seriously than mine. |
From: Derek M. <co...@pi...> - 2012-11-28 00:29:16
|
All, Today I released rssh-2.3.4, which fixes an old issue, and a new issue: On Tue, May 08, 2012 at 01:14:26PM -0500, Derek Martin wrote: > rssh is a shell for restricting SSH access to a machine to only scp, > sftp, or a small set of similar applications. > > http://www.pizzashack.org/rssh/ > > Henrik Erkkonen has discovered that, through clever manipulation of > environment variables on the ssh command line, it is possible to > circumvent rssh. As far as I can tell, there is no way to effect a > root compromise, except of course if the root account is the one > you're attempting to protect with rssh... This was CVE-2012-3478, for which I had originally only posted a patch to the rssh mailing list. It is now fixed in the new release. The new issue is CVE-2012-2252, which involves improper filtering of the rsync command line, when rsync support is configured. This may be somewhat of a non-issue for recent stock rssh installations, as stock rssh does not support newer rsync binaries which use -e to specify the rsync protocol; thus if you're using rssh with a recent istallation, rsync does not work for you anyway, and you therefore most likely have it disabled by config. Nevertheless, it is a legitimate security concern if you have rsync enabled in the configuration. This also is fixed in 2.3.4. This release also includes some mostly trivial updates for the build and a bit of minor code clean-up. For people using rssh packages from Debian, Red Hat, or one of their derivatives, a third vulnerability was recently discovered, assigned CVE-2012-2251. This issue exists only in a third-party patch to make rssh work with newer rsync binaries. Stock rssh *is not vulnerable* to this issue. However if you are relying on your vendor to package rssh, this likely affects you. Lastly, since the vendors are providing their own packages, and I'm no longer set up to build RPMs, I am no longer providing rssh in RPM form. Please be sure to update rssh to v2.3.4, either by downloading and compiling from the website, or by updating your vendor's packages. http://www.pizzashack.org/rssh/downloads.shtml Thank you. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |