Bug 1952

Summary: Local port forwarding does not work in a particular condition.
Product: Portable OpenSSH Reporter: Adam <seifer1983>
Component: sshdAssignee: Assigned to nobody <unassigned-bugs>
Status: NEW ---    
Severity: normal CC: djm
Priority: P2    
Version: 5.8p1   
Hardware: Itanium   
OS: HP-UX   

Description Adam 2011-11-29 18:39:24 AEDT 
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.
Comment 1 Damien Miller 2011-12-02 10:55:08 AEDT 
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).
Comment 2 Adam 2011-12-02 19:07:52 AEDT 
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).