similar to: rssh: root privilege escalation flaw

PIZZACODE SECURITY ALERT program: rssh risk: low[*] problem: string format vulnerability in log.c details: rssh is a restricted shell for use with OpenSSH, allowing only scp and/or sftp. For example, if you have a server which you only want to allow users to copy files off of via scp, without providing shell access, you can use rssh to do that. Additioanlly, running rsync, rdist, and cvs are

> $ rsync -e 'ssh -v' lingnu.com: > OpenSSH_5.1p1 Debian-2, OpenSSL 0.9.8g 19 Oct 2007 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Connecting to lingnu.com [199.203.56.105] port 22. > debug1: Connection established. ... > debug1: Sending command: rsync --server --sender -de.L . As we can see, rsync runs ssh, and

I just released rssh version 2.2.3 to fix the problem detailed below. I haven't had time to update my website yet, and my Internet acess is quite limited these days (hence the terse announcement), so I probably won't get to that for a while. However, rssh 2.2.3 is available from the sourceforge.net site: http://sourceforge.net/projects/rssh All users of rssh should update to the

rssh is a small shell whose purpose is to restrict users to using scp or sftp, and also provides the facilities to place users in a chroot jail. It can also be used to lock users out of a system completely. William F. McCaw identified a minor security flaw in rssh when used with chroot jails. There is a bug in rssh 2.0 - 2.1.x which allows a user to gather information outside of a chrooted jail

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm pleased to announce that rssh now has per-user configurations! Today I released rssh v2.1.0 with that last peice of functionality to be added, bringing active development of rssh to a close. Additionally, I spent several hours testing and debugging this release as thoroughly as I could think to, and I'm pleased to report (tongue in cheek)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I released rssh v2.0.4 today. It fixes bugs in the parser which affect quoted arguments in the config file, as well as the code which builds the vector for the arguments to the exec call. In the latter case, arguments which contain a space were treated as two sepearate args. The man page was also updated to include information about quoting values

Since rsync 3.0 i've detected a problem with rssh and -e option....rssh doesn't allow this option...but is essential to me (cyphered transmission with ssh). Surfing the net i've seen a guy that made a patch but I don't know how reliable is...and rssh former programer says he just left the project so it's no longer his problem. Is this stuff going to be updated in rsync or is

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, Today I released rssh 1.0.4. rssh is a small replacement shell that provides the ability for system administrators to give specific users access to a given system via scp or sftp only. For downloads or more information, visit the rssh homepage: http://www.pizzashack.org/rssh This release fixes a stupid bug caused by a failure to

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [This came over BUGTRAQ this morning. Note the call for volunteers vis-a-vis rssh.] - ----- Forwarded message from Jason Wies <jason at xc.net> ----- List-Id: <bugtraq.list-id.securityfocus.com> List-Subscribe: <mailto:bugtraq-subscribe at securityfocus.com> To: bugtraq at securityfocus.com Cc: rssh-discuss at

List, I am putting together a sftp server and would like to use a restrictive shell with a chroot jail. I was wondering what members of the list thought about rssh as opposed to scponly. Greg Ennis

Hi, As per the subject line - if I look up setting up chroot jails for SFTP over SSH2 I'm led to various Web sites and patches and also to a CentOS wiki page dated 2005, but what's the 'best' or 'correct' way to set this up for Centos 4.5 and 5? Thanks

Hi, On CentOS 7 I?m trying to set up a chrooted SFTP server on which specific users can only read and write on specific folder. And I?d like to disable some commands, so the users can only do ?cd?, ?ls?, ?get? and ?put? (and disabling ?chgrp?, ?chmod?, ?chown?, ?df? etc ?). Is there a way to achieve it, natively or with using a third-party software ? Alexandre MALDEME Analyste d'exploitation

I worked on a proposal like this a few years back (including proof of concept code).? I taught sftp to have an scp personality (closer to scp2 than scp), and it was rejected by the higher ups.? It may have been the dual-personality issue, but I know the scp2 concept was also rejected at the time as it was stated there should be one transfer tool. But the only way to drag scp into this century

I installed Rails and Rubygems on a web server for a customer who wants to install a Ruby on Rails application that he developped. He needs SSH access to interact with Ruby, so I''ll have to grant him access, but I want him to only play around in his /home directory, as this server also hosts other customers. How could I do that? Thanks, -- Posted via http://www.ruby-forum.com/.

I am using sftp-server chroot patch: http://marc.info/?l=openssh-unix-dev&m=116043792120525&w=2 Works fine, except user is able to ssh in box. I could change users shell to /usr/libexec/sftp-server, but then chrooting wouldn't work. What is secure way to accomplish this, so that I could give friend ssh access, so that he could upload/download stuff, but not compromise my system or

Hi! I do not know if it's the ideal place, but I'm sending some suggestion. Always use openssh and its enormous features. - I needed to create an environment with only sftp access and thus used: - Match User suporte ForceCommand / usr / lib / openssh / sftp-server OK! It worked perfectly! But only sftp. - Create an environment with only blocking the ssh, but scp and

I was trying to use rsync to send files to a fileserver using an rssh restricted server. It refuses, saying that trying to override the shell with -e is forbidden. I didn't type "-e". When I look at the source, I see /* Checking the pre-negotiated value allows --protocol=29 override. */ if (protocol_version >= 30) { /* We make use of the -e

Hello, I'm new to the list, but hopefully I've done enough digging around that I don't get yelled at too terribly ;) We're looking to implement a chrooted environment for allowing users to scp files from servers. That's basically the only functionality that we need in this case. We're looking to chroot the user and/or remove any chance that the account can login via

Good Morning All, Attached is a full patch [or so I hope] enabling chroot support for sshd. I know varied opinions about chroot exist among the masses; however, I continue to believe that until something far outside the scope of openssh tackles the sandbox issue, the role of enforcer will continue to be with the daemon. This patch is based on a previous work by John Furman as well as Eric

Hello List, Do I get it right that I *MUST* chroot a user first and make /bin/rssh his shell in the /etc/passwd to effectively restrict him? There should be no /bin/ksh (or bash) in his jail? If I do not jail him - no matter what is his passwd shell - he will be able to issue "ssh user at server /bin/sh" still, right? -- Best regards, Anthony mailto:rz1a at