Red Hat Bugzilla – Bug 190141
sshd port forwarding stopped working as of glibc-2.3.6-3.
Last modified: 2007-11-30 17:11:31 EST
Description of problem: Previously, on the same machine, I was able to create ssh connections to my server and use the port forwarding to access systems on my local network. After my last yum update on April 21 where glibc-2.3.6-3 was installed (along with a few other things), sshd port forwarding now longer works. I now get the error: Forwarded connection refused by server: Administratively prohibited [open failed] Version-Release number of selected component (if applicable): glibc-2.3.6-3 How reproducible: Errors out every time now. Steps to Reproduce: 1. yum update to get glibc-2.3.6-3 and other items 2. try to use the port forwarding when connecting to the updated server 3. receive error message Actual results: Forwarded connection refused by server: Administratively prohibited [open failed] Expected results: I expected to be able to connect to other machines on my local network as I have been able to until April 21. Additional info: I check the open-ssh project web site and found no references to this issue there.
I'm sorry but I cannot reproduce this problem here. Which client version do you use? Could you try to run the server with sshd -ddd and attach the debug output here? Could you do the same on client? (ssh -vvv ....)
This is actually using PuTTy version 0.58 as my client. I've also used the current development tip version of PuTTy with the same negative results. I'll put together th requested -ddd and -vvv output files tomorrow when I have a spare moment -- might be kind of hard to get the -vvv files or the equivalent since I'm using PuTTy though. We'll see. Thanks, Jeff G.
Created attachment 128467 [details] Putty ssh client logging
Created attachment 128468 [details] Log file from running -ddd parameter with sshd
Upon further investigation, this issue where forwarding isn't happening is when I specify the host using its DNS name. If I specify an IP address, then the forwarding works OK. I would be the first to point a finger at my DNS configuration, but this all worked just fine before I did the April 21 yum update. Also, DNS name resolution to IP address works fine on the server and the client machines with other applicaitons. Thanks, Jeff G.
What prints 'host webcam2.test.org' when you run it on the server?
Please note that I text replaced my domain name with "test.org" log files that I posted after I ran the tests. I made this change for privacy reasons. With that being said, I've run the test that you requested and again made the same change afterwards: $ host webcam2.test.org webcam2.test.org has address 192.168.0.121 This DNS name translation to IP address is correct.
Created attachment 128478 [details] Testcase Can you try compiling and running this testcase as './testgai webcam2.test.org 80'?
I don't think it is a problem of sshd, but of the glibc. I have similar problems with other programs when using glibc-2.3.6-3 on my i386 fc4: scp -P 22 somehost:x . fails with a "System error" scp somehost:x . succeeds scp -P 22 someip:x . succeeds (somehost is the full qualified host name, someip is number.number.number.number) (note that ssh works in all configuration) ncftp somehost fails with a "segmentation fault" ncftp someip succeeds yum list (or update, etc) fails with "Cannot find a valid baseurl for repo..." obviously, it could not fetch the mirror list. nxclient (from NoMachine) fails also with a "System error" All of this works nicely if I downgrade glibc to 2.3.5-10.3 I don't have any named running. My resolv.conf contains three nameserver lines and a "search localdomain" line. "host somehost" works correctly, and "./testgai webcam2.test.org 80" gives "getaddrinfo succeeded". I am back to using glibc-2.3.5 to have a usable system. I can make some more test, but I need to "upgrade" glibc, make the tests and downgrade it. It would be nice if you could batch the tests you ask me to do...
-> glibc
Results of testcase execution below: $ ./testgai webcam2.test.org 80 getaddrinfo succeeded Thanks, Jeff G.
Just remove nisplus from your nsswitch.conf. *** This bug has been marked as a duplicate of 186592 ***
I can confirm that removing the nisplus entries from my /etc/nsswitch.conf file is a valid work-around to resolve this issue. Thanks, Jeff g.