企业官网建设流程全解析

1. 项目概述：为什么要在 WSL 里搭一个 Alpine SSH 门户

先说结论：这个项目本质上就是在 Windows 的 WSL 环境里装一个 Alpine Linux，把它当做一个常驻的 SSH 入口机，外部设备通过 SSH 连进来之后，就能进到本地 Linux 环境干活。

我最初的需求其实很朴素：手头有几台内网设备需要统一管理，但平时的主要工作机是 Windows。Windows 自带的 OpenSSH 服务端我也试过，配起来不算难，但一想到要在 PowerShell 和 CMD 之间来回切，还要处理 Windows 防火墙那套交互弹窗，就觉得别扭。相比之下，直接用 WSL 里的 Linux 来做 SSH 服务端，所有配置都是 Linux 那一套熟悉的玩法，文本配置文件改起来顺手，权限体系也天然接近生产环境。

为什么选 Alpine，而不是直接在 WSL 里装 Ubuntu 或者 Debian？核心原因是资源占用。Alpine 的 rootfs 压缩包不到 3MB，装完基础环境也就占用几十 MB 磁盘空间，内存 idle 状态下占用可以压到 30MB 以内。作为一台专门跑 SSH 服务的门户机，它不需要桌面、不需要编译工具链，甚至不需要 Python，只需要内核、shell、SSH 守护进程这三样东西就足够了。用 Ubuntu 跑同样的服务，光基础镜像就要 400MB 起步，日常内存占用也是几百 MB 的量级，放在一台还要跑开发环境的 Windows 上，就显得非常奢侈。

这里说的"门户"还有一层含义：把 SSH 访问 WSL 的通道做通之后，你可以在这个入口上做很多延伸。比如通过 SSH 隧道去访问 WSL 里面跑的开发服务，或者把几个 Windows 机器上的 WSL 环境当跳板机，甚至给内网的一台树莓派做端口转发管理。总之，Alpine 只干一件事，就是做那个轻量、干净、好维护的入口。

这个项目适合谁？三类人大概率用得上：

• 日常主力工作机是 Windows，但习惯用 Linux 命令行工具链的开发者；
• 有内网设备、远程机器需要 SSH 管理，想在 Windows 下搭一个统一跳板入口的人；
• 对资源占用敏感，希望用最小成本在 WSL 里跑一个常驻服务的人。

整个方案做完之后，你可以在任何一台装了 SSH 客户端的设备上（手机 Termius、平板、别的电脑），直接连接 Windows 机器上的这个 Alpine 入口，进入一个干净的 Linux shell 环境。整体配置时间取决于你的熟练程度，我慢悠悠操作一遍也就二十分钟。

2. 整体设计与方案选型

2.1 为什么把"门户机"放在 WSL 而不是虚拟机里

最开始我也认真考虑过要不要直接开一个轻量虚拟机，比如虚拟机软件里跑个精简 Linux，专门做 SSH 门户。但对比之后发现，WSL 有几个明显优势是虚拟机替代不了的。

第一，启动速度。WSL 的发行版是作为一个轻量进程跑在 Windows 上的，会话启动通常在 1~2 秒内完成，不需要像虚拟机那样走完整套 BIOS 引导、内核加载的流程。你配好自启之后，开机就在后台待命，用户根本感知不到它的存在。

第二，网络集成。WSL2 虽然用的是 NAT 网络模式，但 Windows 会自动做 localhost 回环转发，也就是说你在宿主机的 127.0.0.1 上监听一个端口，宿主机直接就能访问，甚至局域网内其他机器通过宿主机 IP 也能访问（这个后面要专门配防火墙规则）。这一步省去了虚拟机里常见的网络类型选择和端口映射配置。

第三，资源回收机制。WSL2 有一个很有意思的特性：当一段时间没有会话接入时，虚拟机会自动回收空闲内存（通过 .wslconfig 里的 autoMemoryReclaim 配置还可以更激进）。对于门户机这种低负载常驻服务，这种弹性是虚拟机没法比的。

当然虚拟机有虚拟机的好处，比如更彻底的内核隔离、可以跑 systemd、可以自定义内核参数。但就"轻量 SSH 门户"这个需求来看，WSL2 的短板完全不影响使用，优势却很贴合场景。

2.2 SSH 服务端选型：Dropbear 还是 OpenSSH

Alpine 的软件仓库里有两个主流的 SSH 服务端，一个是 OpenSSH，另一个是 Dropbear。绝大多数人第一反应会装 OpenSSH，因为它是事实标准，功能全、兼容性好。但我在这个项目里选择了 Dropbear，理由如下：

• 二进制体积更小。Dropbear 的服务端加客户端加起来才几百 KB，OpenSSH 即使精简过后也明显更胖。对于一台内存本身就紧张的迷你门户机来说，这一点很有吸引力。
• 内存占用更低。Dropbear 每个连接的内存开销大约是几 MB 级别，OpenSSH 则要十几 MB。虽然两者都能轻松跑，但"门户"这个定位决定了它应该尽可能轻。
• 配置足够用。门户机核心需求是密钥认证、端口转发、远程 shell，这几项 Dropbear 全都原生支持。

Dropbear 也有不足，比如不原生支持 SFTP（需要配合 sftp-server 程序），对某些 OpenSSH 专属配置项不识别。如果你需要在这台机器上做 SFTP 文件传输，那直接装 OpenSSH 更省事。我的建议是：纯 SSH 用途选 Dropbear，需要 SFTP 或者想跟 OpenSSH 生态无缝衔接就选 OpenSSH。如果你动手能力尚可，也可以先装 Dropbear，后面真要用到 SFTP 再切换到 OpenSSH，切换成本其实很低，无非是 apk add / 改配置文件 / 重启守护进程这三步。

2.3 网络拓扑简析：WSL2 的 NAT 结构中流量怎么走

理清 WSL2 的网络模型，是后面配置不出幺蛾子的前提。WSL2 实际上跑在一个轻量虚拟机里，用的默认网络模式是 NAT。WSL 实例自己有一个虚拟网卡，IP 通常是 172.x.x.x 段，Windows 宿主机通过虚拟交换机跟它通信。

当你在 WSL 里启动一个 SSH 服务监听 0.0.0.0:2222 时，流量路径是这样的：

• 局域网设备发起连接，目标是 Windows 宿主机 IP 的 2222 端口；
• 请求先到达 Windows 网卡，由 Windows 的端口转发机制把流量导向 WSL2 虚拟机的对应端口；
• WSL2 虚拟机内部的 SSH 守护进程接收连接，完成认证，建立会话。

Windows 在 WSL2 里实际上做了一次端口转发（通过 localhost 回环和 ipv4 防火墙规则联合实现）。这意味着你不需要在 WSL 里面配置任何端口转发规则，只需要确保 Windows 防火墙放行了对应端口即可。这个认知很重要，因为很多新手把这套链路想复杂了，跑去 WSL 里 iptables 一通操作，结果完全没用，原因在于流量根本没走到那一步。

3. 环境准备：Alpine 跑进 WSL 的关键几步

3.1 确认 WSL 版本与虚拟机平台已就绪

在动手装 Alpine 之前，先在 PowerShell 里确认两件事：WSL 版本和默认版本号。

# 检查 WSL 版本信息 wsl --version # 查看当前已安装的发行版 wsl --list --verbose

如果 wsl 命令输出提示找不到，或者版本是老的 WSL1，你需要先启用 WSL 功能并更新内核：

# 以管理员身份运行 PowerShell wsl --install --no-distribution

这个命令会安装 WSL2 所需的虚拟机平台组件并更新内核。装完重启一次系统，然后再执行wsl --set-default-version 2，确保后续导入的发行版默认跑 WSL2。WSL1 也能用，但网络转发和自启体验差很多，建议别用。

另外建议在用户目录下放一个.wslconfig文件，给 WSL 资源使用量做个约束。尤其你打算让 SSH 门户常驻后台，最好限制内存和 CPU，避免它跟 Windows 上的其他应用抢资源。我用的配置如下：

[wsl2] memory=2GB processors=2 autoMemoryReclaim=gradual networkingMode=mirrored

注意最后一行networkingMode=mirrored需要较新的 Windows 版本和 WSL 版本才支持。这个模式的好处是：WSL 直接共享宿主机网络栈，SSH 服务启动后局域网内其他设备可以直接访问，省掉很多转发绕路。如果你的系统不支持，没关系，直接用默认 NAT 模式也完全可以，只是后面需要确认 Windows 防火墙转发规则。

3.2 下载 Alpine minirootfs 并导入 WSL

Alpine 官方提供的 minirootfs 是最小化的 rootfs 压缩包，一般只有几 MB。去官方下载页面挑对应架构（x86_64 或 arm64）的 minirootfs 压缩包，文件名形如alpine-minirootfs-3.20.0-x86_64.tar.gz。

下载之后在 PowerShell 里执行导入命令：

# 建议专门建个目录存放 WSL 虚拟磁盘文件 mkdir D:\WSL\Alpine cd D:\WSL\Alpine # 导入（注意 --name 后面是发行版名称，可自定义，这里用 alpine） wsl --import Alpine D:\WSL\Alpine alpine-minirootfs-3.20.0-x86_64.tar.gz --version 2

导入完成后，先直接进入默认 root 用户环境：

wsl -d Alpine

这时你会看到 Alpine 的 root shell，但需要注意：这个默认 root 用户是没有密码的，安全起见必须先设置密码。在 Alpine 里改 root 密码用passwd命令即可，然后立刻退出。

3.3 Alpine 基础初始化：换镜像源与基础包安装

Alpine 默认的镜像源在国外，如果网络指向国内，apk 拉取软件包的速度会非常感人。碰到这种情况，建议换成国内镜像源。编辑/etc/apk/repositories，主要改动版本号对应的 URL 前缀。Alpine 的软件包源地址格式如下：

https://mirrors.域名/alpine/v3.20/main https://mirrors.域名/alpine/v3.20/community

把你对应地区的镜像站前缀替换进去，保存后执行：

apk update

接着安装一套基础工具，我这里按实用原则选择：

apk add bash tzdata curl vim openssh-client

tzdata是时区数据，不装的话系统时间可能显示 UTC，对 SSH 日志排查很不友好。装完后设置时区：

ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime echo "Asia/Shanghai" > /etc/timezone

基础环境到此就绪。这一步看起来简单，但有几个细节容易踩坑：Alpine 的默认 shell 是 busybox ash，很多习惯 bash 的人会觉得命令补全和 PS1 显示别扭，所以提前装好 bash 并设置chsh切到 bash 会很舒服；另外 Alpine 默认 glibc 并不存在，它是 musl libc，所以想装某些需要 glibc 动态链接的二进制的软件可能会失败，这是 Alpine 的特性，做门户机影响不大，但心里要有数。

4. 配置 SSH 服务：从安装到可远程登录

4.1 安装 Dropbear 并调整基本配置

在 Alpine 里安装 Dropbear 非常简单：

apk add dropbear

装完默认服务并不会自动启动，需要手动启动一下：

rc-service dropbear start

把服务加入默认运行级别，这样重启后它会随系统启动：

rc-update add dropbear default

Dropbear 的配置文件在/etc/conf.d/dropbear，你可以编辑它来调整监听端口、启动参数。默认情况下它监听所有网卡的 22 端口。因为我们这里是门户场景，不想用容易被扫描的 22，可以改为 2222 端口，同时限制监听地址：

# /etc/conf.d/dropbear DROPBEAR_OPTS="-p 0.0.0.0:2222"

如果你只是本机用，监听 127.0.0.1:2222 更安全；需要局域网访问则监听 0.0.0.0:2222。改完配置重启服务：

rc-service dropbear restart

验证一下是否在监听：

netstat -tlnp | grep 2222

看到0.0.0.0:2222 LISTEN就说明服务起来了。我去掉 OpenSSH 之后特意测试过，从宿主机执行ssh localhost -p 2222应该能立刻看到 Dropbear 的认证提示。

4.2 如果选择 OpenSSH 的配置方式

有的读者会觉得 Dropbear 小众不习惯，那用 OpenSSH 也可以。在 Alpine 上装 OpenSSH 服务端：

apk add openssh-server mkdir -p /run/sshd rc-service sshd start rc-update add sshd default

OpenSSH 的配置文件在/etc/ssh/sshd_config，针对门户机的核心配置我一般只保留这一段：

# /etc/ssh/sshd_config 关键部分 Port 2222 AddressFamily inet PermitRootLogin prohibit-password PasswordAuthentication no PubkeyAuthentication yes ClientAliveInterval 60 ClientAliveCountMax 3

PermitRootLogin prohibit-password的意思是允许 root 登录但仅限于密钥认证，这比完全禁止 root 登录要方便，因为门户机日常就一个 root 用户。PasswordAuthentication no直接砍掉密码登录，只能密钥登录，安全等级直接拉满。OpenSSH 修改配置后也要重启：

rc-service sshd restart

这里要留意一个细节：Alpine 用的是 OpenRC，不是 systemd，所以没有systemctl restart sshd这种玩法，只能rc-service来管。因为 WSL2 的会话生命周期比较特别，rc-service在 WSL 里是能用的，但需要依赖 OpenRC 的初始化系统正常加载。这也是为什么后面需要专门做自启脚本——实际上 WSL 启动 shell 时并不一定会跑 OpenRC 的 default 运行级别。

4.3 密钥登录配置：安全门户的核心底座

无论选 Dropbear 还是 OpenSSH，密钥登录都是必须的第一件事。在宿主机 Windows 上生成一对密钥（如果你还没有）：

ssh-keygen -t ed25519 -C "ssh-gateway-key"

指定保存位置C:\Users\你的用户名\.ssh\id_ed25519之后，生成出公钥和私钥。把公钥内容复制出来，在 WSL 门户机里配置：

# 进入 root 家目录 cd /root mkdir -p .ssh chmod 700 .ssh echo "你的公钥内容" > .ssh/authorized_keys chmod 600 .ssh/authorized_keys

密钥文件权限是最容易踩坑的地方。Dropbear 和 OpenSSH 对私钥、公钥文件的权限要求都很严格，过宽直接拒绝。.ssh目录必须是 700，authorized_keys必须是 600，如果配置文件里指向的私钥是 644，服务端会直接判定不安全并拒绝用这个密钥。我最初在图省事把 authorized_keys 设成了 644，结果客户端一直提示 Permission denied，排查半天发现就是权限问题。

配置完成后测试密钥登录，在 Windows 终端里执行：

ssh root@localhost -p 2222

如果一切正常，应该直接进入 Alpine 的 shell，不需要输入密码。如果第一次连不上，报错信息里出现Permissions too open之类的关键字，优先检查.ssh目录和文件权限。

4.4 SSH 门户开机自启：让服务无人值守

WSL 里比较麻烦的一点是，它默认没有一个常驻的 init 系统去帮你在系统启动时拉起服务。WSL 实例是在你第一次执行wsl -d Alpine时才启动，而且回头看看你会发现，如果你只想让它后台跑着，每次还得手动进入一次。

做自启有两条路线：

路线一：在 Windows 的计划任务里配置开机任务，任务内容让 WSL 启动 Alpine 并在后台执行rc-service dropbear start。操作步骤是：打开"任务计划程序"→ 创建任务 → 触发器选择"计算机启动时" → 操作里填：

wsl.exe -d Alpine -u root rc-service dropbear start

再把任务设置里的"最高权限"勾上。实测过，这个方案每次开机都会执行，即使 WSL 还没启动，这个命令也会把 WSL 实例拉起来然后执行服务启动命令。唯一要注意的是 WSL 实例首次启动可能慢半拍到一秒，服务启动命令本身幂等，多执行几次没有副作用。

路线二：WSL2 较新版本支持在/etc/wsl.conf里配置[boot]段，可以指定一个启动时执行的命令：

[boot] systemd=true command="service dropbear start"

systemd=true是较新 WSL 版本的特性，可以让 WSL 内部真正运行 systemd（或者用command直接执行传统 sysvinit 风格命令）。不过 Alpine 在 WSL 里对 systemd 的支持我不太推荐，毕竟 Alpine 的原始 init 系统是 OpenRC，systemd 是后加的模组，稳定性要打折扣。我更推荐方案一，靠 Windows 计划任务来控制启动时机，排查问题也简单——任务管理器里能看到有没有跑。

我在实际项目中用了一个更隐蔽的"伪常驻"手法：把 WSL 的.wslconfig里的autoMemoryReclaim=gradual开启后，即使没有人连接，WSL 虚拟机的内存会在低负载时自动回收，虽然进程还在运行，但是不占太多资源。这样 SSH 门户就像真的"常驻"在后台一样，几乎察觉不到它的存在。

5. 网络打通与安全加固

5.1 Windows 防火墙放行与端口转发确认

门户机最核心的网络问题就是：局域网内其他机器怎么访问到你 WSL 里的 SSH 服务。

在默认 NAT 网络模式下，WSL2 会自动把从宿主机发往 localhost 的流量转发到 WSL 实例。也就是说，你在 Windows 命令行里执行ssh localhost -p 2222一定通。但其他局域网设备访问宿主机IP:2222时，情况就不同了。

要确认 Windows 防火墙是否拦截了 2222 端口。如果第一次在其他设备上连接超时，多半是防火墙拦了。以管理员身份在 PowerShell 里执行：

# 放行 TCP 2222 端口 New-NetFirewallRule -DisplayName "WSL-Alpine-SSH" -Direction Inbound -Protocol TCP -LocalPort 2222 -Action Allow

如果是旧的 Windows 版本或默认网络配置下，你可能还需要手动加一条端口转发规则，从宿主机 IP 转发到 WSL 实例 IP。在 WSL 里查一下它的网卡 IP：

ip -4 addr show eth0

看到类似172.24.xx.xx的地址后，在管理员 PowerShell 里执行：

netsh interface portproxy add v4tov4 listenport=2222 listenaddress=0.0.0.0 connectport=2222 connectaddress=172.24.xx.xx

不过要提醒你，如果你的.wslconfig里已经设置了networkingMode=mirrored，就不需要 netsh 这一步，直接放行防火墙就能通。newwsl 的 mirrored 模式是直接把 WSL 套进宿主机网络栈，连端口转发都帮你做了。

5.2 安全加固的几件套：非默认端口、密钥认证、限IP、限算法

门户机的安全加固思路跟任何公网 SSH 服务器一样，优先级从高到低如下：

第一，密码认证必须关闭。前面配置已经做了PasswordAuthentication no，这是最核心的一条。宁可丢密钥也不能留密码登录的口子，因为密码爆破的成本太低了。

第二，非默认端口。默认 22 端口每分钟会被扫描器问候无数遍，即使你密码关掉了，日志里也是一堆登录尝试噪音。改到 2222 或更高位端口，能减少 90% 以上无差别扫描。

第三，白名单模式。如果只有特定的几个 IP 需要访问，直接配置防火墙只放行这些来源。Windows 高级防火墙里可以给前面创建的规则绑定 RemoteAddress 条件。不过咱们一般在内网用，这一步按需做即可。

第四，限制登录频率。Dropbear 没有自带 fail2ban 那种插件机制，但 Alpine 可以直接装 fail2ban：

apk add fail2ban

不过考虑到门户机的轻量取向和单用户规模，我个人觉得 f2b 是过度的。实在想加，用 Docker 或者定时任务去扫日志封 IP 也行，毕竟一台只做 SSH 服务的内网机器被人持续爆破的概率并不高。

第五，SSH 算法收紧。OpenSSH 可以去掉已经不推荐的算法（如 diffie-hellman-group1-sha1），避免一些老版本的安全问题。Dropbear 相对省心，它的默认算法集本身就比较克制。

5.3 连接超时与保活参数：别让会话频繁断线

用 SSH 门户机的过程中，最常见的体验问题就是"挂了一会儿自动断了"。原因有两个：一是网络中间设备（比如家用路由器）会清理空闲连接；二是服务端本身有超时策略。

Dropbear 的配置里可以通过-K参数设置保活间隔，OpenSSH 则用ClientAliveInterval和ClientAliveCountMax。我建议设置客户端空闲 60 秒时服务端发送一次保活探测，连续 3 次没响应才断开连接：

# OpenSSH 配置项 ClientAliveInterval 60 ClientAliveCountMax 3

如果你是 Dropbear，启动参数加上：

DROPBEAR_OPTS="-p 0.0.0.0:2222 -K 60"

这样即使你人离开电脑去倒杯水，会话通常也能保持一整天不断。另外在客户端侧，OpenSSH 配置里ServerAliveInterval 30也是对称的保活机制，两边配合起来，长会话基本告别断连。

5.4 Windows 侧 SSH 客户端与 WSL 互联互通的额外技巧

门户机跑起来之后，Windows 侧其实也能玩出不少花样。比如把 WSL 里的ssh命令包装到 Windows PATH 里，这样你在 PowerShell 里直接执行ssh root@localhost -p 2222就能进入门户，而不需要先wsl -d Alpine再连。

具体做法：在 Windows 用户环境变量 PATH 中加上C:\windows\system32\wsl.exe所在路径，之后 PowerShell 里直接敲：

wsl -d Alpine

如果你想把端口直接变成别名访问，可以创建一个小脚本，把sshenter定义为ssh root@localhost -p 2222，放到C:\Users\你的用户名\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1里：

function sshport { ssh root@localhost -p 2222 }

这样每次打开 PowerShell 执行sshport就能秒进 Alpine。这种"cmd 别名 + WSL 门户机"的模式，让我日常在 Windows 和 Linux 之间切换的体验提升了一个档次。

6. 常见问题与排查技巧实录

6.1 连接被拒绝 / 超时

现象：Windows 本机执行ssh localhost -p 2222提示 Connection refused。

排查顺序：

1. WSL 里执行netstat -tlnp | grep 2222看服务是否真的在监听；
2. 如果没监听，rc-service dropbear start手动起一次；
3. 如果有监听，检查 Dropbear 配置文件是否指定了错误地址，比如限制了127.0.0.1但实际监听0.0.0.0；
4. 如果监听正常，看宿主机侧的防火墙有没有拦截回环流量（一般不会）。

现象：局域网其他机器连接宿主机 IP 超时。

排查顺序：

1. 在宿主机 PowerShell 里执行Test-NetConnection 宿主机IP -Port 2222看端口是否可达；
2. 不可达，先确认防火墙规则里 Direction 是 Inbound 且允许 TCP 2222；
3. 再看 .wslconfig 是否用了 mirrored 模式，如果有但设备不支持，就按默认 NAT 配置加 netsh portproxy；
4. 路由器上如有防火墙策略，检查是否需要端口放行。

6.2 密钥认证失败 / Permission denied

这个坑我见得太多了。客户端提示 permission denied 的首选嫌疑是权限，尤其是authorized_keys和.ssh目录的权限过宽。把服务端审计打开，在sshd_config里设置LogLevel VERBOSE，重启服务后看/var/log/messages的报错信息。大多数时候能看到Authentication refused: bad permissions这样的明确提示。

6.3 WSL 重启后服务没起来

WSL 实例的启动机制决定了，如果你从来没有主动进入过 Alpine，它的服务自启可能不会生效。默认情况下 WSL 实例是在第一次连接时启动，只有 Windows 计划任务才能保证开机后就立刻拉起服务。所以我建议自启动方案用 Windows 任务计划程序触发wsl -d Alpine -u root rc-service dropbear start，不要依赖 WSL 内部的rc-update行为。

6.4 端口被占用 / 无法绑定

有时候程序提示socket: Address already in use，多半是之前的 SSH 服务进程没被完全杀掉，或者另一个进程占用了 2222 端口。用lsof -i:2222找出进程然后 kill 掉即可。有时候 Windows 更新或网络重置会导致 Hyper-V 虚拟网卡重启，WSL 实例 IP 发生变化，原来配的 netsh portproxy 目标地址就失效了。这种情况可以用 PowerShell 脚本在每次开机时动态获取 WSL IP 并刷新 portproxy 规则，网上有很多现成脚本，我习惯是直接写个巡航任务跑一遍。

6.5 时区不对导致日志时间混乱

修改完时区后，记得重启 SSH 服务才会读取新时区。否则日志里显示的时间戳跟实际对不上，排查问题时容易产生误导。如果改了/etc/timezone还不生效，就同步/etc/localtime软链接，然后重启 sshd。

6.6 小技巧速查表

7. 实际操作中的心得与后续扩展

这个项目我已经跑了一个多月，中间踩过的坑基本都写在上面的排查清单里了。如果要总结一条最重要的经验，那就是：门户机越简单越抗折腾。别急着往里塞各种工具链和脚本，它的价值就体现在"轻"字上，任何超过基础 SSH 需求的功能都往别的地方放，不要在门户机上堆砌。

另外一个感悟是，自启方案一定要在 Windows 侧做，别指望 WSL 内部的开机自启脚本，因为 WSL 实例的启动时机你控制不住。当时我一度在 /etc/profile.d 里写了个启动服务脚本，发现有时生效有时不生效，折腾一圈才明白是实例没有真正"启动"过。换了计划任务之后，再也没出现过开机连不上的问题。

项目后续可以扩展的方向至少有这几个：

• 加一层证书登录（比如使用 SSH CA 给密钥发短期证书），适合团队成员动态加入的场景；
• 把 SSH 端口转发做成更通用的隧道，比如从手机 SSH 到门户机再跳转访问内网服务；
• 接一个轻量监控脚本，定时探测门户机存活状态并把结果写到 Windows 事件日志；
• 如果你已经把 WSL 切到 mirrored 网络模式，甚至可以再开一个 Caddy 做 web 反向代理，让门户机顺带变成内网仪表盘的入口。

最后再分享一个小技巧：配置完门户机后，把宿主机 Windows 的 OpenSSH 服务端关掉，避免多个 SSH 服务在相同端口上互相打架。很多人在同一台 Windows 上既开了系统自带的 sshd，又在 WSL 里开了 SSH 门户，局域网里访问 22 端口时行为会很迷惑。保证只有一个入口，这台门户机的价值才能真正体现出来。