為什麼 wget 不能通過 ssh 隧道工作?代理阻止 ssh-client 做什麼?
為了測試我正在嘗試通過 建立從筆記型電腦到站點的本地 ssh 隧道
ssh-server
,並下載該站點的頁面(或在瀏覽器中查看)。隧道是這樣製作的:
$ ssh -L 9999:www.gnu.org:80 ssh-server
我檢查隧道是否與伺服器上的
nc
程序和字元一起使用。~#
我檢查我是否允許通過在伺服器上執行wget
和lynx
在 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
儘管如此)。