通过ssh隧道转发端口9000的xdebug远程调试 - 如何使其工作？

Question

I have XAMPP 1.7.3a running on an "Amazon Linux" (Centos-derived) 32-bit instance in the Amazon EC2 cloud. I downloaded/built/installed XDEBUG 2.1.0. The relevant items in phpinfo() output look like this:

Directive                         Local Value  Master Value
xdebug.idekey                     ECLIPSE_DBGP ECLIPSE_DBGP
xdebug.default_enable             On           On
xdebug.remote_autostart           On           On
xdebug.remote_connect_back        Off          Off
xdebug.remote_cookie_expire_time  3600         3600
xdebug.remote_enable              On           On
xdebug.remote_handler             dbgp         dbgp
xdebug.remote_host                127.0.0.1    127.0.0.1
xdebug.remote_mode                req          req
xdebug.remote_port                9000         9000
xdebug.remote_log                 /opt/lampp/logs/xdebug_log
                                               /opt/lampp/logs/xdebug_log

I access the Linux box from a Windows laptop running XP SP3, using the SSH client in PuTTY version 0.60. Also on the laptop I've installed Eclipse PDT (Helios Service Release 1 Build id: 20100917-0705), and I think I've got it configured correctly to do XDEBUG remote debugging using port 9000. I say I think, because I've had difficulty figuring out how to do that, and how to use Eclipse PDT in general. But I did manage to get it configured and working for "remote" debugging of PHP code run by web pages served using XAMPP for Windows 1.7.3 on localhost (127.0.0.1), using port 9000. The phpinfo() output for the server on the laptop which PDT is able to debug is the same as above, except for:

xdebug.idekey       my_username     no value
xdebug.remote_host  localhost       localhost
xdebug.remote_log   no value        no value

I'm pretty sure these differences are not related to the problem. In fact, xdebug.idekey was originally "root novalue" on Linux, which I then changed to ECLIPSE_DBGP by both editing php.ini and setting environment variable DBGP_IDEKEY in the sudo-ed script that starts apache, in vain hope of getting things working.

I've got firewalls and a NAT router between the laptop and the Linux box. So I am trying to use port forwarding through a PuTTY ssh tunnel to get the Linux XDEBUG talking to the Windows PDT. I've been using X11 forwarding with PuTTY for a couple of months with no problems at all. I set up the tunnel in PuTTY with local port 9000 forwarded to port 9000 on the Linux box, and port 9000 on the Linux box forwarded to port 9000 on 127.0.0.1, the PuTTY tunnel panel showing:

L9000  host...amazonaws.com:9000
R9000  127.0.0.1:9000

Looking at the PuTTY Event Log when the tunnel is set up, there appear to be no problems:

2010-11-16 18:07:59 Local port 9000 forwarding to host...amazonaws.com:9000
2010-11-16 18:07:59 Requesting remote port 9000 forward to 127.0.0.1:9000
2010-11-16 18:07:59 Remote port forwarding from 9000 enabled

But then when I go to PDT and click Debug on a configuration that specifies the remote web server, PDT shows background activity in the lower right corner that gets stuck at 57%, and if I click the icon to go to Progress view, that shows "Launching: waiting for XDebug session".

When this happens, the PuTTY Event Log shows:

2010-11-16 19:05:42 Received remote port 9000 open request from 127.0.0.1:54474
2010-11-16 19:05:42 Attempting to forward remote port to 127.0.0.1:9000
2010-11-16 19:05:42 Forwarded port opened successfully
2010-11-16 19:05:42 Opening forwarded connection to host...amazonaws.com:9000
2010-11-16 19:05:42 Forwarded connection refused by server: Connect failed [Connection refused]
2010-11-16 19:05:42 Forwarded port closed

On the Linux box, /var/log/secure just shows:

Nov 16 19:01:51 ip-10-194-9-67 sshd[14555]: error: connect_to host...amazonaws.com port 9000: failed.

I've checked my /etc/ssh/sshd_config, and I think it's okay, even changing it explicitly to "AllowTcpForwarding yes", even though that is supposed to be the default. In my web searches for a solution, I did come across one linuxquestions posting where the final reply says something rather cryptic about sshd needing to resolve a hostname:

this seemed to fix it: The hostname has always been domain-serv, since I always thought of my router as being domain.com...so after running hostname domain.com...bam! It finally works...

I guess sometimes it is too simple. sshd had to be resolving domain.com to my router, ergo the connection failed.

I sounds like this might be related to my problem, but it makes no sense to me, and since it's pretty old, and the author didn't seem to understand it, either, I thought I would ask here rather than there...

I did notice that a similar question was asked in this forum almost a year ago that got just one 0-value response, presumably because the question was so lacking in detail as to be unanswerable. I hope this one has enough information, and isn't so long, so that somebody can steer me right. After reading the faqs and how to ask a question, it wasn't entirely obvious to me whether the correct use of the forum was to post something under that original poorly-asked but content-identical question, or to post this new one - I'm sure someone will let me know what was the right choice on that :-)

I've been going nuts with this thing, and I suspect it's something pretty obvious to someone with experience. I'm a noob to most of this stuff (PHP, web programming, network admin, and this forum), though not to old-fashioned C programming and user-level Linux and Windows setup.

Answer 1

How embarrassing, apparently my port forwarding setup was something only a network noob would do? I guess I had decided that since the Xdebug running on the web server needs to talk to the PDT debugger client on the laptop, and the PDT debugger client on the laptop also needs to talk to Xdebug on the server, and there's only one port number (9000), that therefore I needed to forward local port 9000 to remote port 9000, and also forward remote port 9000 to local port 9000; I was confusing the direction of traffic with which side is the client initiating a (bi-directional) connection to a specific port that the server side is listening to.

What seemed to be happening was that the PDT debugger running on the laptop got stuck waiting for Xdebug running on Linux to make a connection. Since I couldn't really think of a situation where Xdebug would need to be listening to port 9000, waiting for the PDT debugger to initiate a connection (rather it would be waiting for the PDT debugger to send it a command over a connection that had already been established by its opening port 9000 when it saw the XDEBUG_SESSION parameter in the request), I decided just to get rid of the forwarding of local port 9000 to remote port 9000. I did that, and all of a sudden PDT was receiving the connection sent from the Linux server, and debugging proceeded normally from there.

But what's still not clear in my mind is why having the additional forwarding actually caused a problem. Couldn't it be possible for a pair of programs on different hosts to operate such that, depending on state, sometimes one was the listener and sometimes the other was? As long as the forwarding doesn't cause them both try to listen on the same port at the same time, I'd expect that to be okay.

Bottom line is that things seem to be working now because of a simplification I made, but I'd like to understand why the unneeded complexity actually caused a problem. I've read a lot of stuff, including the excellent explanation of ssh and tunneling in the O'Reilly book, but I still don't get it.