openssh bugs - Nov 2011 - [Bug 1952] New: Local port forwarding does not work in a particular combination of conditions.

https://bugzilla.mindrot.org/show_bug.cgi?id=1952

             Bug #: 1952
           Summary: Local port forwarding does not work in a particular
                    combination of conditions.
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 5.8p1
          Platform: Itanium
        OS/Version: HP-UX
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: seifer1983 at gmail.com


OS:
HP-UX B.11.31 U 9000/80 or HP-UX B.11.31 ia64 

Related SSH Version: 
Found on 5.8p1.  I also found this problem on 5.3p1 and 5.6p1, so it
may be in all versions.

Reproduced steps:

1. Update /etc/nsswitch.conf to not resolve "ipnodes" from dns.  Could
set it to resolve "ipnodes" files, nis, or both.  I used files in my
test.

hosts:        dns [NOTFOUND=continue] nis [NOTFOUND=continue] files
ipnodes:      files
networks:     nis [NOTFOUND=continue] files


2. Start SSHD on a private port, i.e. 51220, with below configuration. 
Directory "/adamroot" is set with proper privilege.

Match User adam
ChrootDirectory /adamchroot

3. Start any TCP server application listening on a specific port
number.  I used another SSHD listening on port 51230.

4. On the same machine, start a local port forwarding session. Forward
51230 to local port 51232.

# ssh -L 51232:localhost:51230 -N -f -l adam -p 51220 localhost

5. Start a TCP client app, connect to TCP server started in step 3),
through the forwarded port number in step 4).  I used ssh client in my 
test.

# ssh -l user1 -p 51232 localhost

Step 5 will fail and the tunneling session in step 4) will dump below
message.

channel 2: open failed: administratively prohibited: open failed

When I used SSHD in debug mode and test again, I got below log.

...
connect_to localhost: unknown host (host nor service provided, or not
known)
debug1: server_input_channel_open: failure direct-tcpip
...

It looks like SSHD can not resolve "localhost" in this particular
condition.

You could use any other TCP C/S app to reproduce the problem as long as
you are able to config target host name and listen port.  

Note that if you use a not matched account in step 4) to set up
tunneling, i.e. any account other than "adam" in my test,you will not
meet this problem.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1952

Adam <seifer1983 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Local port forwarding does  |Local port forwarding does
                   |not work in a particular    |not work in a particular
                   |combination of conditions.  |condition.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1952

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> 2011-12-02 10:55:08
EST ---
This looks like a misconfiguration:

When you are in chroot mode, you will need to populate the chroot with
whatever support files your OS needs to support name resolution. This
may include nsswitch.conf, resolv.conf, hosts and possibly even shared
objects for NSS (depending on the platform).

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1952

--- Comment #2 from Adam <seifer1983 at gmail.com> 2011-12-02 19:07:52 EST
---
If you are talking about "/opt/ssh/utils/ssh_chroot_setup.sh", yes,
I've used this script to init chroot directory, which is /adamroot in
my test.

So there are two nsswitch.conf files at /adamroot/etc/ and /etc/.
I changed "ipnodes" in "/etc/nsswitch.conf", removing
"nds" part.
Meantime, "ipnodes" in "/adamroot/etc/nsswitch.conf" as the
default
value, "nds nis file".  I also had the tunneling problem in this
scenario.

Here's another interesting part.  If I put nds at the beginning of
ipnodes, tunneling will be OK.  But if I put either of other two
methods at the beginning, but still have dns behind, I will still has
this problem.  Looks that even the order of "resolve from" will affect
the results.  

If "dns nis files" passed, why just something like "files dns
nis"
should failed?



(In reply to comment #1)
> This looks like a misconfiguration:
> 
> When you are in chroot mode, you will need to populate the chroot with
> whatever support files your OS needs to support name resolution. This
> may include nsswitch.conf, resolv.conf, hosts and possibly even shared
> objects for NSS (depending on the platform).
-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.