Putty设置SSH隧道，隧道和代理的原理区别（KIMI）

本文内容为和AI大模型KIMI的对话记录，仅供参考。

---

User: 我有一台服务器，用putty和winscp能够登录，但是jupyterlab启动后无法从笔记本的浏览器进入，应该如何设置？需要通过ssh隧道吗？
Kimi: 是的，在“只能 SSH 登录、无法直接打开 8888 端口”这种场景下，最省事也最安全的做法就是 建立 SSH 本地端口转发（隧道） ，无需改动服务器防火墙，也无需把 JupyterLab 暴露到公网。下面给出 Windows 下用 PuTTY / WinSCP 以及 命令行 两种常见方式的完整步骤，按任意一种配置完即可在笔记本浏览器里打开远程 JupyterLab。

---

一、服务器端（只需一次配置）

1. 生成/修改配置文件

   jupyter lab --generate-config          # 会在 ~/.jupyter 下生成 jupyter_lab_config.py
   

2. 建议设一个固定登录密码（比每次 token 方便）

   jupyter server password                # 按提示输入，会写入哈希值
   

3. 启动时让 JupyterLab 只监听回环地址（127.0.0.1），避免公网直连：

   jupyter lab --no-browser --ip=127.0.0.1 --port=8888
   

   如果希望后台常驻，可写成 systemd 服务或 nohup ... &。

---

二、笔记本端建立 SSH 隧道

1. 图形界面：PuTTY
   ① 主界面填好服务器地址、端口 22 → 进入左侧菜单
   Connection → SSH → Tunnels
   ② Source port = 8888（本地随便定，未被占用即可）
   Destination = 127.0.0.1:8888
   ③ 选 Local 类型 → Add → 回到 Session 保存并 Open
   登录成功后 保持窗口开着，隧道即生效。

2. 命令行（Windows PowerShell / CMD 均可）

   ssh -L 8888:127.0.0.1:8888 用户名@服务器IP
   

   成功登录后同样不要关闭窗口。

---

三、浏览器访问
打开本地浏览器，地址栏输入

http://localhost:8888

首次访问输入刚才 jupyter server password 设置的密码（或启动时给出的 token），即可进入远程 JupyterLab 界面。

---

四、排错小贴士

• 本地 8888 被别的程序占用 → 把 -L 后的第一个 8888 改成 8889/8899 等，浏览器对应输入 localhost:8889。

• “Connection refused” → 确认服务器端 jupyter 监听在 127.0.0.1:8888；重新启动并查看日志。

• SSH 会话频繁断 → 在 PuTTY 的 Connection → SSH → 右侧 “Seconds between keepalives” 填 30；命令行可在 ~/.ssh/config 里加

  ServerAliveInterval 60
  

• 想用 token 而不是密码 → 启动后终端会给出 http://127.0.0.1:8888/?token=xxxx，复制 token 粘贴到浏览器即可。

采用以上隧道方案，服务器只需开放 22 端口，JupyterLab 本身不暴露在公网，既省防火墙配置又保证安全 。

---

User: SSH隧道的原理是什么？和代理有什么区别？

Kimi: 下面把 SSH 隧道（SSH Port Forwarding）拆成 3 句话先给出“是什么”，再画一张“数据流图”，最后把大家最容易混淆的“SSH 隧道 vs. 通用代理”做一张对照表，一眼就能看出来差别。

---

1. 一句话原理
   “在已经建立的 SSH 会话里再开一条‘加密子通道’，把客户端某端口（或 socket）的数据原封不动转发到服务器侧任意地址:端口，中间所有流量走 22 端口且被 SSH 协议加密/解密，对应用层完全透明。”
2. 数据流图（本地转发为例，访问远程 JupyterLab）

笔记本（浏览器）
↓ 1. HTTP 请求到本地回环 127.0.0.1:8888
↓ 2. 被 ssh 客户端截获 → 加密 → 走 22 端口
公网 / 防火墙
↓ 3. 到达服务器的 sshd → 解密
服务器内部
↓ 4. sshd 把明文转给 127.0.0.1:8888 的 jupyter-lab
↓ 5. 返回数据按同样路径反向流回浏览器

3. 隧道 vs. 代理 对照表

维度	SSH 隧道	SOCKS/HTTP 代理
工作层级	传输层（TCP 四元组转发）	应用层（先告诉代理“我要去哪”，再发数据）
加密范围	端到 SSH 服务器（22 端口以内加密，出服务器后明文）	仅客户端↔代理之间加密与否取决于代理协议本身；SOCKS5 可以无加密
对应用是否透明	完全透明——应用以为自己在连本地端口	不透明——应用必须支持“代理”并主动告诉代理目标地址
能转发什么	任何基于 TCP 的单端口服务（RDP、MySQL、Jupyter…）	SOCKS 可转发任意 TCP/部分 UDP，但应用得支持 SOCKS；HTTP 代理只能转发 HTTP(S)
配置位置	客户端一次性 ssh -L / putty 隧道 → 之后所有程序 0 改动	每个应用单独填写代理地址端口；系统级 PAC/全局代理才算“一次配置”
访问控制	只要 ssh 账号不泄露即可；服务器端不再开新端口	代理服务需要单独做认证、白名单、TLS 等
典型端口	22（对外），内部转发端口任意	1080（SOCKS）、3128/8080（HTTP）
多目标能力	一条隧道 = 一个“本地端口↔远程端口”映射；要转 N 个服务就开 N 条隧道	一条 SOCKS 隧道可同时转发 N 个任意目标，只需在应用里选 SOCKS 即可

---

结论速记

• “端口转发”是 SSH 的内置小功能，借 22 端口把任意 TCP 流穿进去，对应用零改造；
• “代理”是应用层协议，客户端必须主动说“帮我连某某地址”，转发更灵活但需要应用配合；
• 如果你只是要把远程 8888 映射到本地 8888，用 SSH 隧道最简单，也不用再装额外代理软件。