WSL2下用Alpine搭建SSH门户：密钥登录与局域网远程开发

使用Alpine配置WSL ssh门户，听上去是个很小众的操作，但实际做完你会发现，它等于在Windows里埋了一个干净的Linux入口。我这次的目标很直接：让局域网内任何一台设备能通过SSH进入WSL里的Alpine，用上标准的Linux shell、密钥登录、远程开发环境，并且整个过程稳定、安全、不用每次重启都折腾一遍。这篇文章适合正在折腾WSL的开发者和习惯用SSH管理机器的运维朋友。我会从选型思路、系统安装、sshd配置、密钥体系、网络打通到问题排查一条线讲完，尽量把我在实操中踩过的坑和验证过可用的方案都写出来。

1. 项目整体布局：为什么选Alpine做SSH门户

1.1 所谓门户到底是什么

这里的“门户”不是网页入口，而是一个SSH登录入口。你可以把WSL里的Alpine理解成一台微型Linux服务器，它跑在Windows里，对外暴露一个SSH端口。你从其他电脑、手机甚至开发板，用ssh命令连进来，就进到一个干净的Linux shell环境，可以执行命令、远程开发、通过SSH自身的端口转发能力访问WSL内的服务。这就是“门户”的核心价值：Windows是底座，Alpine是门，门后面是完整的Linux工具链和你部署在WSL里的各种服务。

很多人会在Windows上直接安装OpenSSH Server来解决远程登录问题，但用下来你会发现，Windows的OpenSSH始终和系统权限模型绑在一起，密钥管理、authorized_keys路径都和Linux习惯不一样，配起来总觉得别扭。Alpine没有这个问题，它本身就是完整的Linux用户态、进程管理和权限体系。你在生产服务器上怎么配SSH，在WSL里就怎么配，几乎没有迁移成本。这也是我选择这个方案的第一理由：配置心智模型是统一的。

1.2 Alpine相比Ubuntu和Windows自带方案的优势

一提到WSL，大部分人第一反应是Ubuntu，毕竟教程多、生态全。但Alpine在“门户”这个场景里有一个无法忽略的优点：干净、小、启动快。Alpine基础系统加OpenSSH，磁盘占用不到200MB，内存占用常常只有几十MB。Windows里开着它，你几乎感觉不到后台还有一个Linux在跑。Alpine使用musl libc加busybox，包管理是apk，命令风格非常简洁，天然适合做轻量跳板和入口。

Ubuntu适合干活，适合跑完整的开发环境，但如果你的目的只是要一个SSH入口、一个干净的命令行跳板，Ubuntu反而显得重。Windows自带OpenSSH的问题前面说过，还有一个硬伤：登录默认进的是cmd或PowerShell，不是WSL的bash。你想让用户一登录就直接进入WSL，还得额外配置子系统入口，链路多一层，排查起来也麻烦。Alpine做门户，登录即Linux，所有命令都顺手，这才是“门户”应该有的体验。

注意：Windows OpenSSH并非不好，在需要域认证、PowerShell远程管理的场景它是合适的。但目标明确是“WSL ssh门户”时，Alpine是更稳定的通用Linux入口。

1.3 整体架构和流转路径

我的门户结构分三层。最外层是Windows的网络接口和防火墙规则，负责把流量引导到WSL；中间层是Alpine里的OpenSSH Server，负责身份认证和会话管理；最内层是WSL中运行的各种服务，比如Docker容器、开发环境、命令行工具。你在其他设备上执行ssh -p 2222 user@Windows主机IP，Windows把端口数据转给WSL的22端口，Alpine里的sshd完成密钥校验，然后给你一个标准登录shell，整个过程就像访问一台独立Linux服务器。

如果只在本机使用，甚至可以不用端口转发，因为WSL2默认支持从Windows访问WSL的localhost端口，直接ssh user@localhost -p 22就能连进去。但如果要让局域网其他机器访问，端口转发或者镜像网络就必须选一个。WSL2的默认NAT模式里，WSL是一个独立虚拟网段，外部设备摸不到WSL的内部IP，所以这个网络层是门户配置里最容易卡住的地方，后面我会专门写清楚两种打通方式。

2. 环境准备：安装Alpine WSL并让sshd跑起来

2.1 从零安装Alpine发行版

开始之前，先把WSL本体升级到比较新的版本。我建议至少2.0以上，因为后面要用的mirrored镜像网络模式在旧版本上兼容性不好。在Windows的PowerShell里执行：

powershell复制wsl --version
wsl --status

如果WSL本体还没装，先执行：

powershell复制wsl --install

然后单独安装Alpine发行版：

powershell复制wsl --install -d Alpine

Alpine镜像很小，下载时间通常很短。装完第一次启动，用wsl -d Alpine进入，默认是root用户，没有密码。第一步设置root密码，同时更新软件源和包索引：

bash复制passwd root
apk update
apk upgrade

国内网络环境下，Alpine官方源有时候会比较慢。我习惯把dl-cdn.alpinelinux.org替换成镜像站，比如：

bash复制sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g' /etc/apk/repositories
apk update

这一步纯粹是加速下载，不影响后续配置逻辑。如果你在海外或者网络直连官方源很快，跳过即可。

2.2 安装并启动OpenSSH

Alpine基础系统精简到什么程度？连SSH服务端都要自己装。命令很简单：

bash复制apk add openssh
ssh-keygen -A

ssh-keygen -A这一步特别容易漏。它一次性生成所有类型的主机密钥文件，比如ssh_host_ed25519_key、ssh_host_rsa_key等。如果漏掉，sshd启动时会直接报错找不到host key。安装完成后，启动服务：

bash复制rc-service sshd start

正常启动没有输出，可以用rc-service sshd status确认。如果启动失败，先看日志，Alpine的日志通常在/var/log/messages：

bash复制tail -n 50 /var/log/messages

我遇到的一个典型坑是/run/sshd目录不存在。这个目录是sshd运行时存放文件的地方，手动补一下：

bash复制mkdir -p /run/sshd
chmod 0755 /run/sshd

然后再次启动，基本就正常了。

2.3 让sshd在WSL启动时自动拉起

WSL不是完整虚拟机，Alpine的OpenRC也不会像systemd那样由WSL自动托管。如果不处理，Windows每次重启后WSL里的sshd都不会自动运行，除非你手动打开WSL窗口执行一次启动命令。这显然不符合“门户”的预期。我这里有两条可行方案。

方案一是写一个profile脚本。在Alpine里创建/etc/profile.d/ssh-start.sh：

bash复制cat > /etc/profile.d/ssh-start.sh <<'EOF'
#!/bin/sh
rc-service sshd status >/dev/null 2>&1 || rc-service sshd start
EOF
chmod +x /etc/profile.d/ssh-start.sh

只要有人进入WSL的shell，脚本就会检查sshd状态并自动拉起。使用这个方案的前提是至少有一次交互登录，不过日常场景通常没问题。

方案二是用WSL的/etc/wsl.conf的boot.command。在/etc/wsl.conf中写入：

ini复制[boot]
command = "rc-service sshd start"

保存后重启WSL：在Windows执行wsl --shutdown，再wsl -d Alpine。boot.command会在WSL实例初始化时执行，相当于“开机自启”。这个配置需要比较新的WSL版本，老版本不认boot.command。

两个方案可以并存，但没必要。我自己用的是boot.command，如果遇到WSL更新后配置不生效，就降级到profile脚本救急。跑门户的机器，不需要太花哨的启动机制，稳定优先。

3. 建用户、配密钥、锁死root：SSH安全基线

3.1 创建登录用户并加入wheel组

root直接登录SSH是门户的大忌。虽然Alpine默认配置可能允许root登录，但我们要主动把它关掉，然后新建一个日常登录账号。Alpine里创建用户的命令和其他发行版略有不同，但很直观：

bash复制addgroup wheel
adduser alpine

adduser alpine会交互式让你设置密码和填写信息，密码一定要设置一个高强度口令。创建完成之后，把用户加入wheel组：

bash复制adduser alpine wheel

如果你想在登录后还能通过sudo执行管理命令，可以补装sudo，并给wheel组开放sudo权限：

bash复制apk add sudo
echo '%wheel ALL=(ALL:ALL) ALL' > /etc/sudoers.d/wheel

到这里，alpine这个用户既可以SSH登录，又能用sudo做管理操作。Windows侧的远程用户连进来后，默认就在这个受限账号下操作，而不是直接拥有root权限。这个习惯建议从一开始就养成，后面省很多事。

3.2 生成SSH密钥并配置免密登录

免密登录不是偷懒，而是让门户更安全的关键一步。打开PasswordAuthentication no之后，密码爆破基本失效，攻击面一下就小了很多。在你的本机生成一对密钥，推荐用Ed25519算法，性能好、密钥短、安全性足够：

bash复制ssh-keygen -t ed25519 -C "wsl-alpine-portal" -f ~/.ssh/id_ed25519

生成后，私钥是~/.ssh/id_ed25519，公钥是~/.ssh/id_ed25519.pub。私钥绝对不能外传，公钥则要放进Alpine的authorized_keys。最简单的方式是用ssh-copy-id：

bash复制ssh-copy-id -p 22 alpine@localhost

Windows本机连接WSL时，这个命令会要求输入一次alpine的密码，然后自动把公钥追加到~/.ssh/authorized_keys。如果你不想装额外工具，也可以手动复制公钥内容，在Alpine里执行：

bash复制mkdir -p ~/.ssh
echo "你的公钥内容" >> ~/.ssh/authorized_keys

然后设置权限，这一步绝对不能省。权限不对，sshd会拒绝信任公钥：

bash复制chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

权限这里多说一句： ~/.ssh目录必须只有用户自己能读写执行，authorized_keys文件必须只有用户自己能读写。网上很多朋友Permission denied (publickey)查半天，最后发现就是权限多了个group write。

3.3 修改sshd_config：只允许wheel组、禁用root、关闭密码登录

现在开始加固sshd配置。编辑/etc/ssh/sshd_config，我推荐这套基准配置：

code复制Port 22
ListenAddress 0.0.0.0
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowGroups wheel
AllowUsers alpine
MaxAuthTries 3
ClientAliveInterval 60
ClientAliveCountMax 3

逐项解释一下为什么这么配。Port 22是WSL内部监听端口，外部入口可以用Windows端口转发做映射，不必改内部端口。PermitRootLogin no就是“取消root用户SSH登录”，这是门户安全底线。PasswordAuthentication no只保留公钥认证，从此不再有密码爆破的机会。AllowGroups wheel是这一套配置里的精华：只有wheel组成员能SSH登录，要给人开权限就把用户加进wheel组，要收回就从wheel组移除，权限收敛非常清楚。AllowUsers alpine是更细一层的白名单，避免wheel组里有多个用户但只有部分应该登录的情况。MaxAuthTries 3限制认证次数，ClientAliveInterval和ClientAliveCountMax可以让僵尸连接自动断开，避免无谓会话占资源。

改完配置先做语法检查：

bash复制sshd -t

如果提示配置无误，再重启服务：

bash复制rc-service sshd restart

测试的时候建议另开一个终端窗口，不要把自己当前的窗口踢掉。使用：

bash复制ssh -v alpine@localhost

-v会打印详细调试信息，看到Authenticated to localhost就说明密钥链完整。接下来再试着用root登录，应该会被拒绝。到这一步，SSH安全基线的三根柱子已经立起来了：禁root、禁密码、限wheel组。

4. 打通网络：让局域网设备也能连进WSL门户

4.1 WSL2的网络模型和localhost转发的边界

WSL2默认是NAT模式，WSL实例有独立的虚拟网卡和IP，比如172.20.10.5。Windows和WSL之间有一条虚拟链路，Windows可以访问WSL的服务，WSL也可以访问Windows的服务，但局域网里的其他设备默认摸不到WSL的内部IP。什么意思呢？你的手机和Windows处于同一个WiFi下，手机执行ssh user@Windows的局域网IP，请求到达的是Windows网卡，而Windows上如果没有服务监听对应的端口，连接必然失败。

解决思路无非两条。一种是端口转发：让Windows监听一个端口，把数据原封不动转给WSL的22端口，这是NAT模式下最常规的做法。另一种是切换镜像网络：让WSL共享Windows的IP地址，从链路层上抹掉“两个网络”的隔阂。两种方案我都用过，下面把各自的关键步骤和边界说清楚。

4.2 传统方案：netsh端口转发加防火墙规则

在管理员PowerShell里执行端口转发命令：

powershell复制netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=2222 connectaddress=172.20.10.5 connectport=22

这里的listenaddress=0.0.0.0表示监听Windows所有网卡，listenport=2222是对外暴露的端口，connectaddress是WSL里的实际IP，connectport=22是Alpine里sshd的监听端口。WSL的IP获取命令是：

bash复制hostname -I

这条命令可能输出多个IP，取第一个即可。执行完portproxy，还要放行Windows防火墙，否则流量进不来：

powershell复制netsh advfirewall firewall add rule name="WSL SSH Portal" dir=in action=allow protocol=TCP localport=2222

此时，局域网设备就能用ssh -p 2222 alpine@Windows局域网IP连接门户了。这个方案有一个绕不开的缺点：WSL2的IP是动态的，重启WSL之后IP可能会变，portproxy规则里的connectaddress就会失效。所以NAT方案必须配合脚本动态更新，并不优雅。

4.3 更省心的方案：.wslconfig开启mirrored镜像网络

WSL 2.0开始支持镜像网络模式，它让WSL直接共享Windows的网络接口。在Windows用户目录下创建或编辑.wslconfig：

ini复制[wsl2]
networkingMode=mirrored

保存后重启WSL：

powershell复制wsl --shutdown
wsl -d Alpine

开启mirrored之后，Alpine里的sshd监听0.0.0.0:22，Windows的IP就是WSL的IP，局域网设备可以直接执行ssh -p 22 alpine@Windows局域网IP，完全不需要portproxy。但Windows防火墙依然会检查传入连接，所以防火墙放行命令还是要加。如果你不想把内部端口直接暴露成22，可以继续用2222做外部转发，但没必要，直接放行22最简单。

镜像网络模式最大的好处是没有了WSL IP变化的问题，整个SSH链路少了一层转发，排查问题快很多。我目前的主力方案就是它。缺点是如果你的Windows网络栈比较复杂，或者机器上的网卡驱动比较老，镜像模式可能与部分网络功能冲突。一旦发现不兼容，退回NAT加portproxy脚本也不复杂。

注意：修改.wslconfig后，一定要wsl --shutdown彻底重启，不要只执行wsl -d Alpine。很多朋友配置不生效，就是因为WSL实例没有真正重启。

4.4 自动刷新portproxy的PowerShell脚本

如果坚持用NAT模式，那就做一个自动更新portproxy的脚本，避免每次IP变化都手动改。在Windows上创建一个PowerShell脚本，比如Update-WslPortProxy.ps1：

powershell复制$wslIp = (wsl -d Alpine -- sh -c "hostname -I").Trim().Split(' ')[0]
netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=2222
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=2222 connectaddress=$wslIp connectport=22

然后通过任务计划程序创建一个开机或登录触发的任务，操作设置为：

powershell复制powershell.exe -ExecutionPolicy Bypass -File C:\Scripts\Update-WslPortProxy.ps1

脚本里最好加一句Start-Sleep -Seconds 5，因为第一次调用wsl -d Alpine时，WSL可能还在初始化，等几秒再执行netsh更稳妥。这个方案我在老版本WSL上跑过很久，稳定度可以，只是比mirrored模式多了一层脚本依赖。如果你有选择空间，我强烈建议先在mirrored模式下测试。

5. 从VS Code、手机、其他电脑连接门户

5.1 本机VS Code Remote-SSH连WSL

开发场景里最常用的是VS Code的Remote-SSH扩展。安装扩展之后，编辑~/.ssh/config，加一段：

code复制Host alpine-wsl
    HostName 127.0.0.1
    Port 22
    User alpine
    IdentityFile ~/.ssh/id_ed25519

在WSL2未开mirrored时，Windows自带localhost转发，所以用127.0.0.1就能连到WSL里的sshd；开启mirrored后直接写127.0.0.1同样成立。然后VS Code命令面板里选择“Remote-SSH: Connect to Host”，输入alpine-wsl，VS Code会用密钥登录Alpine，自动安装远程扩展，你就能在WSL里编辑代码、跑终端命令了。

有一个小问题容易踩：Windows的SSH客户端如果没有加载私钥，连接时会一直转圈或弹密码。可以在Windows终端执行一次ssh-add ~/.ssh/id_ed25519，把私钥加入SSH Agent。如果还是连不上，回Alpine侧检查authorized_keys权限，我发现大部分连接失败都出在权限上。

5.2 手机和其他电脑连接

手机端我用过Termius和JuiceSSH，配置逻辑和桌面一样：主机填Windows的局域网IP，端口填2222或mirrored模式下的22，用户名alpine，认证方式选择私钥，把之前生成的私钥内容粘贴进去即可。注意Android/iOS客户端一般直接粘贴私钥文本，不需要额外转换格式。其他电脑从局域网连接时，只需要一句命令：

bash复制ssh -p 2222 alpine@192.168.x.x

如果连接超时，优先检查Windows防火墙。很多Windows机器在sshd或者portproxy第一次监听时会弹窗询问是否允许，你没点允许就被拦了。可以主动查看规则：

powershell复制Get-NetFirewallRule -DisplayName "WSL SSH Portal"

没有对应规则就重新加一遍。要始终记得一个模型：流量先到Windows网卡，再到WSL进程，任何一层断掉都会表现为连接失败。

5.3 从门户再往内网跳

门户还有一种常见用法：先SSH到WSL，再从WSL继续SSH到内网其他Linux机器。比如你在一家企业的办公网络里，Windows上的WSL门户是唯一允许登录的跳板，那么在外网或者手机端可以这样连接：

bash复制ssh -J alpine@windowsIP:2222 root@10.0.0.8

-J是OpenSSH的ProxyJump选项，相当于借道WSL去访问内网目标。这个模式在纯内网环境里尤其好用，你不需要给每台机器都开公网入口，只需要保住一个可信的WSL门户，再通过它去连其他机器。WSL Alpine里默认带了OpenSSH客户端，只要网络能通，这条跳板链路就能工作。门户的真正价值也在这里：后端服务不一定在WSL里，WSL只是那个干净的入口和中转点。

6. 常见问题与排查速查

6.1 sshd起不来的几类根因

先讲一个容易让人沮丧的场景：Windows侧wsl --update进行到一半卡住，或者WSL服务启动异常，这时候Alpine可能根本进不去。我的建议是先冷静执行wsl --shutdown，再wsl -d Alpine，确认能不能进入shell。如果连shell都进不去，优先检查WSL版本和发行版是否损坏，不要一上来就怀疑sshd配置。这类问题大多是系统级，不是配置级。

进入Alpine后sshd起不来，排查顺序是：先看/var/log/messages日志，多翻几行。日志中出现no hostkeys相关字样，就执行ssh-keygen -A。出现权限相关错误，就检查/etc/ssh/下主机密钥文件的权限，通常应该是600，属主root。如果提示/run/sshd没有，补上目录即可。这些错误我在不同机器上都遇到过，大部分是安装步骤漏了或者文件权限被改过。

6.2 连接超时和Permission denied的区分

SSH连接失败，先看报错类型。Connection timed out说明流量根本没到达sshd，原因多半在Windows防火墙、portproxy规则或者目标IP不对。Connection refused说明流量已经到机器或端口，但端口上没有进程在监听，优先检查Alpine里的sshd是否运行、端口是否配置正确。Permission denied (publickey)说明你成功找到了sshd，但密钥校验没通过，接下来重点排查authorized_keys内容和权限。Host key verification failed说明这台目标主机在~/.ssh/known_hosts里的主机密钥已经变了，用ssh-keygen -R 目标IP删掉旧记录再重连。

整理成一张速查表会更直观：

6.3 密钥登录后仍要密码？权限检查清单

这个问题出现频率最高。即使你把PasswordAuthentication设成了no，系统仍可能提示输入密码，这通常说明公钥认证根本没有成功。一步步检查：

bash复制ls -ld ~
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

正常状态是：home目录不能让其他用户写，.ssh目录为700，authorized_keys为600。如果home目录成了755，OpenSSH也会抱怨。修复命令：

bash复制chmod 700 ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

另一个隐蔽问题是文件编码或换行符。如果你在Windows里用记事本复制公钥内容，可能把换行符弄成CRLF，sshd读取时认为内容非法。解决办法是重新在Linux里用echo追加公钥，或者执行dos2unix ~/.ssh/authorized_keys清理一下。我遇到过一个用户折腾了足足两天，最后发现就是公钥文件里多了一个Windows空行。细节决定成败。

6.4 关于端口冲突和扫描防护

如果Windows上的其他服务占用了端口，portproxy规则可能不生效。在PowerShell里用netstat -ano | findstr :2222查一下端口占用，如果有进程占着，就换一个端口，比如22222。WSL内部的sshd默认监听22，一般不会冲突，但外部端口的选择尽量避开常用服务端口。

SSH服务一旦对外暴露，日志里大概率会出现大量扫描尝试。我的底线是：只允许密钥登录、禁止root、限制wheel组，这已经是硬性防护。如果追求更严，还可以在Alpine里装fail2ban：

bash复制apk add fail2ban
rc-update add fail2ban default
rc-service fail2ban start

fail2ban会监控sshd日志，连续失败几次就临时封禁来源IP。WSL门户大多在局域网使用，但如果你把它映射到更开放的网络环境，这个习惯一定要养成。

最后留一个我自己的实操经验。刚开始我用的NAT模式加portproxy，WSL的IP一重启就变，隔三差五要跑一次脚本，非常烦。后来切换到mirrored模式，sshd监听22，Windows防火墙放行，局域网设备直接连接，问题彻底消失。如果你的WSL版本支持mirrored，别犹豫，直接换。另外，每次改完sshd_config都先执行sshd -t检查语法，再重启服务，这个习惯能帮你避开九成以上的SSH配置故障。门户这种东西，稳定比花哨重要。