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

发布于 2024-10-03 01:17:17 字数 3880 浏览 0 评论 0原文

我在 Amazon EC2 云中的“Amazon Linux”(Centos 派生)32 位实例上运行 XAMPP 1.7.3a。我下载/构建/安装了 XDEBUG 2.1.0。 phpinfo() 输出中的相关项目如下所示:

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

我使用 PuTTY 版本 0.60 中的 SSH 客户端从运行 XP SP3 的 Windows 笔记本电脑访问 Linux 机器。另外,在笔记本电脑上,我安装了 Eclipse PDT(Helios Service Release 1 Build id:20100917-0705),并且我认为我已经正确配置它以使用端口 9000 进行 XDEBUG 远程调试。我说我认为< /em>,因为我很难弄清楚如何做到这一点,以及如何使用 Eclipse PDT。但我确实设法对其进行了配置,并使用端口 9000 在本地主机 (127.0.0.1) 上使用 XAMPP for Windows 1.7.3 服务的网页运行 PHP 代码的“远程”调试。服务器的 phpinfo() 输出在 PDT 能够调试的笔记本电脑上,与上面相同,除了:

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

我很确定这些差异与问题无关。事实上,xdebug.idekey 最初在 Linux 上是“root novalue”,然后我通过编辑 php.ini 并在启动 apache 的 sudo-ed 脚本中设置环境变量 DBGP_IDEKEY 将其更改为 ECLIPSE_DBGP,徒劳地希望让事情正常工作。

我在笔记本电脑和 Linux 机器之间安装了防火墙和 NAT 路由器。因此,我尝试通过 PuTTY ssh 隧道使用端口转发来让 Linux XDEBUG 与 Windows PDT 进行通信。我已经使用 PuTTY 进行 X11 转发几个月了,没有任何问题。我在 PuTTY 中设置了隧道,将本地端口 9000 转发到 Linux 机器上的端口 9000,并将 Linux 机器上的端口 9000 转发到 127.0.0.1 上的端口 9000,PuTTY 隧道面板显示

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

:隧道已设置,似乎没有问题:

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

但是当我转到 PDT 并在指定远程 Web 服务器的配置上单击“调试”时,PDT 在右下角显示后台活动,该活动卡在 57% 处,如果我单击该图标转到“进度”视图,其中显示“正在启动:正在等待 XDebug 会话”。

发生这种情况时,PuTTY 事件日志显示:

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

在 Linux 机器上,/var/log/secure 仅显示:

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

我已检查了我的 /etc/ssh/sshd_config,我认为没关系,甚至将其显式更改为“AllowTcpForwarding yes” ”,尽管这应该是默认值。在我的网络搜索解决方案时,我确实遇到了一个 linuxquestions 发布,其中最终回复说了一些关于 sshd 需要解析主机名的相当神秘的内容:

这似乎解决了这个问题: 主机名一直是域服务,因为我总是 认为我的路由器是domain.com...所以运行后 主机名domain.com...bam!终于成功了...

我想有时这太简单了。 sshd 必须解析domain.com 到我的路由器,因此连接失败。

我听起来这可能与我的问题有关,但这对我来说没有意义,而且由于它很旧,而且作者似乎也不理解它,我想我应该在这里问而不是在那里问......

我确实注意到大约一年前在这个论坛中提出了一个类似的问题,大概只得到了一个 0 值响应因为这个问题太不详细了,无法回答。我希望这篇文章有足够的信息,而且不要太长,以便有人可以引导我正确。在阅读了常见问题解答以及如何提出问题后,我并不完全清楚论坛的正确使用方式是在最初提出的问题很少但内容相同的问题下发布一些内容,还是发布这个新问题 - 我我确信有人会让我知道什么是正确的选择:-)

我一直对这件事很着迷,我怀疑这对于有经验的人来说是非常明显的事情。我对大部分内容(PHP、Web 编程、网络管理和这个论坛)都是菜鸟,但对老式 C 编程和用户级 Linux 和 Windows 设置不感兴趣。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

奢望 2024-10-10 01:17:17

多么尴尬啊,显然我的端口转发设置只有网络菜鸟才会做?我想我已经决定,由于在Web服务器上运行的Xdebug需要与笔记本电脑上的PDT调试器客户端通信,并且笔记本电脑上的PDT调试器客户端也需要与服务器上的Xdebug通信,并且只有一个端口号(9000),因此我需要将本地端口 9000 转发到远程端口 9000,并将远程端口 9000 转发到本地端口 9000;我混淆了流量方向与客户端发起与服务器端正在侦听的特定端口的(双向)连接的哪一侧。

似乎发生的情况是,笔记本电脑上运行的 PDT 调试器陷入等待 Linux 上运行的 Xdebug 建立连接的状态。因为我无法真正想到 Xdebug 需要侦听端口 9000 的情况,等待 PDT 调试器启动连接(而是等待 PDT 调试器通过已连接的连接向其发送命令)当它看到请求中的 XDEBUG_SESSION 参数时,它已经通过打开端口 9000 建立了),我决定摆脱本地端口 9000 到远程端口 9000 的转发。我这样做了,突然 PDT 收到了从 Linux 服务器发送的连接,调试从那里正常进行。

但我仍然不清楚为什么额外的转发实际上会导致问题。不同主机上的一对程序能否根据状态运行,有时一个是侦听器,有时另一个是侦听器?只要转发不会导致它们同时尝试侦听同一端口,我希望这没问题。

最重要的是,由于我所做的简化,现在事情似乎正在正常进行,但我想了解为什么不必要的复杂性实际上导致了问题。我读了很多东西,包括 中对 ssh 和隧道的精彩解释O'Reilly 的书,但我还是不明白。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文