一次讲清 Windows SSH 免密登录:从能连上,到真正不用输密码

很多人以为 SSH 很复杂，其实它的核心作用只有一句话：

在一台电脑上，安全地连接并管理另一台电脑。

这次我做的事情也很简单：

• 在主控电脑上配置 SSH

• 给远端 Windows 机器开通 SSH 服务

• 做好公钥认证

• 最后把长命令缩短成一个好记的别名

SSH 到底是干什么的

SSH，英文是 Secure Shell。

它的几个常见用途很直接：

1. 远程登录另一台电脑

2. 执行远程命令

3. 管理程序和服务

4. 传输文件，比如 scp、sftp

所以，SSH 本质上就是远程管理的基础入口。

这个场景的结构，其实很简单

可以把它理解成两端：

• 本机：客户端

• 远端电脑：服务端

本质关系就是：

• 客户端运行 ssh

• 服务端运行 sshd

主控电脑发起连接，远端电脑接收连接。  

后面的脚本、自动化任务、远程执行，都是建立在这条通道已经打通的前提上。

Windows 上怎么搭 SSH

如果远端是 Windows，最核心的步骤通常只有这几步。

1. 安装 OpenSSH Server

Windows 已经内置 OpenSSH，只是很多机器默认没开启。

2. 启动 SSH 服务

这样 SSH 服务就会立即启动，并且以后开机自动启动。

3. 在本机生成密钥

建议优先用 ED25519：

它会生成两份文件：

• 私钥：留在本机

• 公钥：部署到远端

免密登录靠的就是“本机拿私钥证明身份，远端保存对应公钥做校验”。

4. 给连接起一个别名

比如在本机 C:\Users\你的用户名\.ssh\config 中写：

这样以后就不用每次输入一长串命令了，直接：

简单高效，后续我直接在这里启用终端，运行codex命令，就可以远程控制电脑部署代码了。

真正容易踩坑的地方

很多人做到这里，会觉得已经结束了：

• 本机密钥有了

• 远端服务启动了

• 公钥也写进去了

• 别名也配了

但现实中最常见的问题是：

你以为公钥“写对了”，其实服务端根本没在读你写的那个文件。

这次最终定位出的关键问题，就是这个。

为什么 authorized_keys 里明明有公钥，还是不生效

如果远端是 Windows，而且登录账号属于管理员组，那么 OpenSSH 往往不会优先读取用户目录下的：

而可能改为读取：

这就是很多人卡住的根因。

不是密钥错了，也不是本机配置错了，而是服务端真正生效的公钥文件位置变了。

最终正确做法

先确认远端账号是不是管理员组成员：

如果是，那么就要重点检查服务端的 sshd_config，以及管理员专用公钥文件。

典型处理方式是：

1. 确认服务端实际读取哪个 authorized_keys

2. 把公钥写到正确位置

3. 修正文件权限

例如，管理员组场景下，常见生效文件是：

并且这个文件的权限不能太松，否则也可能被 OpenSSH 拒绝。

怎么判断自己到底成功没有

不要靠感觉，直接测试。

在本机执行：

如果这两条命令都能直接返回结果，没有再要求输入密码，就说明公钥认证已经真正打通。

这比“好像能连上”更可靠。

最后记住这三点

第一，本机 config 正常，只代表客户端配置生效。  

第二，公钥已经生成，不代表服务端就一定在读你写入的那个文件。  

第三，Windows 上如果涉及管理员组，必须额外关注 administrators_authorized_keys 这类规则。

SSH 免密登录真正难的，从来不是命令本身，而是把客户端和服务端各自负责什么想清楚。

一旦这一层打通，后面的远程管理、脚本执行和自动化任务，才会真正顺起来。