similar to: Chroot patch (v3.4p1)

This patch adds a new option to sshd, chroot_users. It has the effect of chroot()ing incoming ssh users to their home directory. Note: this option does not work if UsePrivilegeSeparation is enabled. Patch is based on OpenSSH 3.4p1. *** servconf.h@@\main\1 Tue Oct 1 17:25:32 2002 --- servconf.h Wed Oct 2 06:17:48 2002 *************** *** 131,136 **** --- 131,137 ---- char

While I was trying to get the patch to work on one of my AIX hosts (4.3.3), I discovered what is probably a bug in the section of code in session.c. for (i = 0; i < options.num_chroot_users; i++) { if (match_user(pw->pw_name, hostname, ipaddr, options.chroot_users[i])) { dir = chroot_dir(pw); /* 'dir' now points to memory block holding pathname */

Could people please test -current? We will be making a release fairly soon. -d -- | By convention there is color, \\ Damien Miller <djm at mindrot.org> | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE)

Hello, I came across an interoperability problem in OpenSSH 3.0p1 and 3.0.1p1 concerning the AFS token forwarding. That means that the new versions are not able to exchange AFS tokens (and Kerberos TGTs) with older OpenSSH releases (including 2.9p2) and with the old SSH 1.2.2x. In my opinion this problem already existed in Openssh 2.9.9p1, but I have never used this version (I only looked at the

Hello, I came up with this scenario of the use of batch mode while thinking of back-up schemes to use for myself. However, it could be that the last step needed in this scenario is not supported by rsync! Here's the scenario: At one time, /c/home/wer/work and /e/gold had identical content and were really huge (say, 200 GBytes). After some complex, intricate work, Mr. Wer

https://bugzilla.mindrot.org/show_bug.cgi?id=2681 Bug ID: 2681 Summary: postauth processes to log via monitor Product: Portable OpenSSH Version: 7.4p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at

Dovecot is faulting on an error about permissions that it shouldn't do. I've got an user with its home dir with permissions 700, and inside the mail directory with the mboxes. In the error log I can see: 'Can't chdir to /home/user. Permission denied' I wonder why it has to chdir to that directory and why it can't access. Shouldn't it be running as the user?

The way this was last supplied to this list (2002-07-13) has the chroot after the call to 'setpcred'. In AIX 4.3.3 the call to setpcred changes the uid and eff. uid to the user attempting to logon. Then the call to chroot( new_home ) fails because AIX requires that any user issuing the chroot subroutine be at root authority. Net result: attempting to do a chroot after the call to

Would anybody happen to have or know of a patch to make /etc/default/login PATH and SUPATH the default openssh path? We have customized paths for each school of engineering (each have their own customized site bin). This is easily controled with /etc/default/login. The --with-default-path option is too rigid. This is Solaris I am talking about. --mike

While I was updating our ssh-servers, I rewrote my old patch that adds idletimeout (just like in old ssh1) parameter to openssh. Since reapplying the patch for all new versions of openssh is not fun at all, I would like to have it included in the official openssh, if you consider the patch worthy. Unlike ClientAlive, idletimeout works for both protocol versions. It also works together with

It appears that openssh has inherited the dos attack that ssh is susceptible to. This has been discussed on Bugtraq (see http://securityportal.com/list-archive/bugtraq/1999/Sep/0124.html for the thread). There does not appear to be an official for ssh. Attached below is a simple, proof of concept, patch that adds a MaxConnections to sshd_config that sets the maximum number of simultaneous

------------ Original Message ------------ > Date: Sunday, April 19, 2015 18:44:43 +0000 > From: Sarogahtyp <sarogahtyp at web.de> > To: centos at centos.org > Subject: [CentOS] yum install failiure - CentOS-7 - Base > > I have a running CentOS 6.5 64-bit system running and i like to > have a CentOS 7 chrooted system inside. > Ive done that chroot environment as

Hi, We are preparing to make the release of OpenSSH 4.8 soon, so we would greatly appreciate testing of snapshot releases in as many environments and on as many operating systems as possible. The highlights of this release are: * Added chroot(2) support for sshd(8), controlled by a new option "ChrootDirectory". Please refer to sshd_config(5) for details, and please use this

The patch below (against openssh 3.2.3p1) adds a CheckMaxStartups option, defaulting to yes, to determine whether sshd calls drop_connection(). The motivation behind this is twofold. In our environment, our timesharing machines get enough incoming connections that will trigger spuriously with the default value (10 forked unauthenticated connections) as well as some significantly higher values,

We have a system on which users are given a very restricted environment (their shell is a menu) where they should not be able to run arbitrary commands. However, because their shell is not statically linked, ld.so provides a nice clutch of holes for them to exploit. The patch below adds a new configuration option to sshd which quashes their attempts to set LD_PRELOAD etc. using ~/.ssh/environment

I'm reading this fine article on O'Reilly: http://linux.oreillynet.com/lpt/a//linux/2001/11/08/ssh_keystroke.html <quote> The paper concludes that the keystroke timing data observable from today's SSH implementations reveals a dangerously significant amount of information about user terminal sessions--enough to locate typed passwords in the session data stream and reduce the

A short while ago, I looked at using the AllowUsers configuration option in openssh (v3.8p1 , but I believe this to be unchanged in 3.9p1) to restrict access such that only specific remote machines could access specific local accounts. I swiftly discovered that a) specifying wildcarded IP numbers to try to allow a useful IP range was pointless: if I specified AllowUsers joe at

How reasonable, acceptable and difficult would it be to "enhance" openssh so authorizations using kerberos (specifically kerberos tickets) consulted the authorized_keys file? And to be a bit more precise... consulted authorized_keys so it could utilize any "options" (eg. from=, command=, environment=, etc) that may be present? I'm willing to make custom changes, but

Heya, I'm trying to convince my company to use OpenSSH instead of the commercial SSH version. I need a little help: 1. What features does OpenSSH offer over commercial SSH (besides being free and open source of course)? 2. Our lawyers want details on the licensing / patents stuff. I have the high level details from the OpenSSH page. I need the nitty gritty like RSA patent# and

Hi, This patch (against the current CVS tree) is intended to add secure configuration to icecast 'out of the box'. It adds two configuration directives, 'icecast_user' and 'chroot_dir'. These are intended to be used together to reduce the privileges icecast runs under to the minimum necessary. When this is enabled and run as root icecast will enter the specified chroot