openssh bugs - Nov 2004 - [Bug 951] SSH2 protocol breaks pam chroot auth

http://bugzilla.mindrot.org/show_bug.cgi?id=951

           Summary: SSH2 protocol breaks pam chroot auth
           Product: Portable OpenSSH
           Version: 3.9p1
          Platform: Other
               URL: ---
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: PAM support
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: schwarz at power-netz.de


If PAM is enabled in sshd_config , the chroot option of pam does 
only work, if protocol 1 of ssh is used. 

we configured chroot to /opt/root/ . If  I login with an none privileged user
with ssh1 , everything works as expected. I get into /opt/root/home/...
If i use the same user / server  with ssh2 i get to /home/... outside the choot!

We can not say in which version the bug first occured.  We made a quicktest 
with openssh3.9p1 compiled for linux i386 which shoed the same bug.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=951

schwarz at power-netz.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|---                         |---



------- Additional Comments From schwarz at power-netz.de  2004-11-09 02:58
-------

# This is ssh server systemwide configuration file.

Port 22
Protocol 2,1
ListenAddress 0.0.0.0
#ListenAddress ::
HostKey /etc/ssh/ssh_host_key
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin no
#
# Don't read ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# Uncomment if you don't trust ~/.ssh/known_hosts for
RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
StrictModes yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd yes
KeepAlive yes

# Logging
SyslogFacility AUTHPRIV
LogLevel INFO

RSAAuthentication yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
PermitEmptyPasswords no
KbdInteractiveAuthentication yes

UseLogin no
UsePam yes

# Uncomment if you want to enable sftp
Subsystem       sftp    /usr/libexec/sftp-server
MaxStartups 10:30:60
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

UsePrivilegeSeparation no                  



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=951





------- Additional Comments From dtucker at zip.com.au  2004-11-09 16:39 -------
What does your PAM configuration for sshd look like?

If you disable KbdInteractiveAuthentication and enable PasswordAuthentication
does it still do the same thing?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=951





------- Additional Comments From schwarz at power-netz.de  2004-11-09 18:32
-------
You reqwuested this information:

cat /etc/pam.d/sshd
#%PAM-1.0
auth       required     /lib/security/pam_pwdb.so shadow nullok
auth       required     /lib/security/pam_nologin.so
account    required     /lib/security/pam_pwdb.so
password   required     /lib/security/pam_cracklib.so
password   required     /lib/security/pam_pwdb.so shadow nullok use_authtok
session    required     /lib/security/pam_pwdb.so
account    required       /lib/security/pam_chroot2.so        

To answere your question, we did not check that, but we will.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=951





------- Additional Comments From dtucker at zip.com.au  2004-11-09 19:12 -------
OK, I think this is happening because you're using pam_chroot in the
"account"
stack.  For reasons I won't go into here, in the case of SSHv2
challenge-response authentication the call to pam_acct_mgmt() (which invokes the
account stack) happens in a process that's not an immediate ancestor to the
user's shell.  (For the gory details on why see bug #688).

This doesn't happen with password authentication, so it ought to behave as
you
expect, but it probably means the root-owned parent sshd is chrooted too (which
may cause some problems, eg with logging).

I think you should change your PAM config so pam_chroot is a "session"
module,
assuming yor module supports it (the pam_chroot in LinuxPAM does).  That way it
should work for both SSHv1 and SSHv2 no matter what the authentication method,
and will probably work with PrivilegeSeparation too.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=951

schwarz at power-netz.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From schwarz at power-netz.de  2004-11-10 19:48
-------
The PAM confpatch for sshd works for us.

The suggested changes in sshd_config for sshd itself,
did not work.

Thanks to all.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=951

schwarz at power-netz.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.