Ssh

為什麼 wget 不能通過 ssh 隧道工作?代理阻止 ssh-client 做什麼?

  • June 5, 2013

為了測試我正在嘗試通過 建立從筆記型電腦到站點的本地 ssh 隧道ssh-server,並下載該站點的頁面(或在瀏覽器中查看)。

隧道是這樣製作的:

$ ssh -L 9999:www.gnu.org:80 ssh-server

我檢查隧道是否與伺服器上的nc程序和字元一起使用。~#我檢查我是否允許通過在伺服器上執行wgetlynx在 ssh-server 上執行 http 請求——它們都執行沒有錯誤。

但是當我wget --no-proxy localhost:9999在筆記型電腦上執行時,我收到錯誤 403。

我可以使用ssh ssh-server 'wget -O - http://www.gnu.org/' >> whatever. 但是為什麼隧道不起作用?

所以我想弄清楚發生了什麼以及代理不允許什麼樣的事情。

我的猜測是代理專門阻止 ssh-client 執行 http 請求。是這樣嗎?

如果是這樣——代理如何將 ssh-client 與其他程序區分開來?它可以區分來自 ssh-client 的請求和來自另一個程序的請求嗎?

“將 ssh-client 屏蔽到另一個程序”(或其他通過代理的方式)的常用方法是什麼?

PS 如果有人在評論中寫了一個免費的 ssh-server 的地址來測試 ssh-tunneling 和其他東西,那就太棒了。(通常 ssh-servers 不允許免費使用隧道。)

您還沒有設置(或嘗試使用)HTTP 代理,也沒有設置 ssh 隧道。相反,您通過 ssh 使用埠轉發。

轉發 TCP 埠不適用於 HTTP。訪問 HTTP URL 在兩個不同的點使用 URL 的域。1 - 查找要向其發送消息的 IP 地址。2 - 用於 HTTP 消息中的 Host 標頭。這使一個 IP 地址可以為多個域的網站提供服務。

因此,當您訪問時http://localhost:9999/,HTTP 消息包含一個標題行Host: localhost:9999。GNU 網路伺服器不為名為 的網站提供服務localhost:9999,並拒絕訪問 (403)。

(403 是規範合法的。理論上,403 有點不友好,你應該更喜歡帶有消息的 400。就我個人而言,我在我的瑣碎 DynDNS 網站上使用 403。不是按照規範的安全性,而是因為 FORBIDDEN 非常好用於故障排除的強烈信號。希望它甚至足以否認我的網路伺服器攔截了他們的印象(例如,在 DNS 記憶體過時的情況下))。

方便的方法是使用 SSH“動態埠轉發”選項-D,它設置一個 SOCKS 代理。不幸的是 wget 沒有 SOCKS 代理的選項(curl儘管如此)。

引用自:https://unix.stackexchange.com/questions/78345