在 Windows 11 上，PowerShell 提供了对 SSH （Secure Shell）安全外壳协议的支持，可以方便地安装、配置和管理 SSH （Secure Shell）安全外壳协议服务。Windows 11 自带了 OpenSSH （OpenBSD Secure Shell）客户端和服务端，下面是如何启用和配置它们的步骤。

SSH （Secure Shell）安全外壳协议。是一种运行在应用层、基于加密技术的网络协议，核心作用是保障远程登录、远程命令执行、数据传输等操作的安全性，能够有效防止通信过程被窃听、篡改，是目前广泛使用的远程运维、安全访问方案。

OpenSSH （OpenBSD Secure Shell）是 SSH 安全外壳协议的开源实现版本，最初诞生于 OpenBSD 开源操作系统项目，后续发展为独立的开源项目，目前是绝大多数类Unix、Linux 系统，以及新版 Windows 系统默认预装的 SSH 客户端/服务端工具，相比商业闭源 SSH 实现，它的代码完全开源可审计，安全性更高，也完整支持远程登录、安全文件传输（sftp、scp）、端口转发等 SSH 协议的核心能力。

OpenSSH（OpenBSD Secure Shell）的演进是开源安全软件史上一个典型案例，其发展深刻反映了开源社区对安全性、代码审计能力和协议标准化的执着追求。以下是其关键演进阶段及里程碑式 起源（1999年）

背景：原始SSH协议（由Tatu Ylönen于1995年开发）早期版本（SSH 1.x）存在专利限制和安全缺陷。当时自由实现（如ssh-1.2.12）因许可证问题（非GPL兼容）和代码质量堪忧，未被BSD社区接受。
转折点：1999年，Theo de Raadt（OpenBSD创始人）领导OpenBSD团队fork了自由版本的ssh-1.2.12，目标是创建一个完全自由、可审计、无专利纠纷的SSH实现，并移植到OpenBSD操作系统。
首个版本：OpenSSH 1.0随OpenBSD 2.6一起发布（1999年12月），最初仅支持SSH 1.0协议。核心原则：代码必须经得起彻底审计，默认禁用已知危险特性。

SSH 2.0过渡与协议标准化（2000-2003年）

挑战：SSH 1.x存在密钥恢复攻击（如CRC-32漏洞）和协议设计缺陷。IETF正在标准化更安全的SSH 2.0协议（RFC 4251-4254）。
OpenSSH的响应：
- OpenSSH 2.0（2000年）率先实现SSH 2.0协议栈，成为首个广泛部署的SSH 2.0自由实现。
- 主动淘汰SSH 1.x：OpenSSH 3.0（2001年）开始默认禁用SSH 1.x（除非显式启用），推动整个行业向SSH 2.0迁移。
- 创新：集成**SFTP（SSH文件传输协议）**作为子系统（取代易受中间人攻击的旧scp/rcp），成为OpenSSH最具影响力的贡献之一。

安全硬化与特性扩展（2004-2010年）

抗攻击机制：
- 引入Privilege Separation（权限分离）。（OpenSSH 3.2+, 2002）：将SSH守护进程拆分为低权限子进程处理网络流量，极大降低了远程代码执行风险（后成为行业标准）。
- 添加基于哈希的known_hosts（OpenSSH 4.4, 2007）：防止入侵者通过窃取known_hosts文件获得目标列表。
功能增强：
- 改进的密钥管理：ssh-agent转发安全增强、AuthorizedKeysCommand（灵活密钥验证）。
- 证书认证（OpenSSH 5.4, 2009）：引入SSH证书（非传统X.509），简化大规模集群的密钥管理（由Google等大厂推动）。
- 端口转发细粒度控制：PermitTunnel、StreamLocalBindMask等指令。

现代化与后量子准备（2011年至今）

协议与加密现代化：
- 逐步禁用弱算法：如MD5、96位MAC、diffie-hellman-group1-sha1（OpenSSH 6.5+, 2014）。
- 默认启用强椭圆曲线：Curve25519、Ed25519（OpenSSH 6.5+）。
- 引入后量子密钥交换（KEX）实验支持：如sntrup761x25519-sha512@openssh.com（基于NTRU，OpenSSH 8.2+, 2020）和hybernikemlkem761x25519-sha512@openssh.com（OpenSSH 9.0+, 2022），为NIST PQC标准做准备。
沙盒化与系统集成：
- 扩展Privilege Separation：使用seccomp-bpf（Linux）、capsicum（FreeBSD）、pledge/OpenBSD）等系统调用过滤（OpenSSH 5.9+, 2011）。
- 集成FIDO/U2F硬件密钥（OpenSSH 8.2+, 2020）：支持YubiKey等进行二次认证（sk-ecdsa-sha2-*密钥类型）。
可移植性巩固：OpenSSH-portable项目（维护兼容Linux、FreeBSD、Windows等非OpenBSD平台的版本）成为事实上的标准实现，被所有主要Linux发行版、macOS（至Ventura）和Windows 10/11（通过Win32-OpenSSH）采用。

安全事件响应与持续改进

OpenSSH以快速、透明的漏洞响应著称。例如：
- CVE-2016-0777/0778（客户端信息泄露）：OpenSSH 7.2p2（2016）在漏洞公开后数日内发布补丁，并默认禁用有问题的UseRoaming特性。
- CVE-2023-38408（前身认证绕过）：OpenSSH 9.3p2（2023）及时修复。
开发模式：严格的代码审查流程（OpenBSD风格）、偏好简单性over特性堆砌、默认安全（Secure by Default）。

为什么OpenSSH成为事实标准？

安全基因：源于OpenBSD的审计文化，代码量相对较小（~80k C行），易于审计。
标准推动力：早期且完整实现SSH 2.0/RFC，迫使商业SSH厂商（如SSH Communications Security）开源或退出市场。
可移植性成功：OpenSSH-portable团队（由OpenBSD核心成员领导）确保了在异构环境中的一致性。
持续创新：不仅跟随标准，还主动驱动改进（如SFTP、证书、FIDO支持、PQC实验）。
信任背书：被美国政府（NSA/CISA推荐）、金融机构、云服务提供商（AWS EC2默认使用）等高安全需求场景广泛采用。

现状与未来

当前版本：OpenSSH 9.6（2024年中期）继续强化沙盒、添加量子抗性混合KEX选项，并改进审计日志。
未来方向：
- 深化后量子密码学集成（等待NIST PQC标准最终定稿）。
- 增强元数据保护（如掩盖连接时间/长度）。
- 进一步减少攻击面（例如，探索更极权限的子系统架构）。
- Windows原生集成深化（尽管Windows已采用OpenSSH-portable，但微软持续贡献补丁）。

OpenSSH的演进证明：真正的安全不是靠“秘密算法”，而是靠公开审计、激进的默认安全姿态和对威胁的持续适应。它不仅是一个工具，更是开源社区如何通过协作构建基础安全设施的典范。

Windows 内置 OpenSSH（OpenBSD Secure Shell）完整演进历程

一、前置阶段：无原生 SSH 时代（Windows XP ~ Windows 10 1703）

生态痛点

Windows 长期无官方 SSH 实现，跨平台远程管理依赖三类替代方案：

第三方闭源工具：PuTTY、Xshell、SecureCRT，需单独下载、分发、授权管理；
兼容层移植：Cygwin/MinGW 编译 OpenSSH，体积庞大、权限与 Windows 账户不兼容；
微软私有方案：WinRM（WS-Man）、PsExec，协议私有、配置复杂、日志与加密强度弱于 SSH。

底层背景

OpenSSH 原生归属 OpenBSD 项目，使用 LibreSSL 加密库；2015 年微软启动 Win32-OpenSSH 开源移植工程，直接对接 OpenBSD 上游代码，而非重新自研加密栈，保证跨平台行为一致。

二、阶段 1：Beta 预览版落地（Windows 10 1709 / Server 1709，2017 秋）

交付形态

以「按需可选功能 FoD（Feature on Demand）」上线，标注 Beta 测试版，分客户端、服务端两套组件Microsoft ...。
- 客户端：ssh.exe / scp.exe / sftp.exe / ssh-keygen.exe / ssh-agent.exe
- 服务端：sshd.exe，注册为 Windows 系统服务 sshd
安装限制

必须联网从 Windows Update 下载载荷，WSUS 离线环境易报 0x800F0954 安装失败；LTSB 长期服务版无内置安装包。
关键局限
- 未深度适配 Windows 权限模型，NTFS ACL、用户 SID 映射存在 bug；
- 不原生支持 PowerShell 远程会话，默认仅调用 cmd；
- 企业生产环境不推荐部署，仅面向开发者测试。
标志性变化：微软在 GitHub 开源 Win32-OpenSSH 仓库，同步向上游 OpenBSD 提交 Windows 兼容补丁。

1709可选功能Beta界面

三、阶段 2：正式 GA 商用可用（Windows 10 1803，2018 春）

状态升级：移除 Beta 标签，转为正式支持组件，加密栈升级为 LibreSSL 7.6p1，修复心脏出血类历史风险。
能力补齐
- 完整支持 Ed25519、ECDSA 新型密钥，兼容 Linux 标准密钥格式；
- 服务端支持公钥登录、sshd_config 配置文件与类 Unix 语法；
- CMD/PowerShell 双终端兼容，支持管道、文件跨端传输。
短板：仅桌面端支持，同期 Windows Server 无官方 OpenSSH，服务器运维仍只能用第三方工具。

四、阶段 3：全平台标准化预装（Windows 10 1809 / Server 2019，2018 冬，里程碑版本）

核心突破：客户端、服务端全产品线全系统正式支持

桌面端 Windows10 1809

OpenSSH Client 随系统介质预装，仅需手动启用；Server 仍为可选 FoD 组件，无需额外下载大安装包Microsoft ...。
服务器 Windows Server 2019

服务器产品线首次官方搭载 OpenSSH，成为微软推荐跨平台远程管理方案，替代老旧 WinRM/PsExec；管理员可通过 PowerShell 一键部署：
powershell
# 安装客户端 Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 # 安装服务端 Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
架构深度融合（关键演进点）
- 原生对接 Windows 本地账户、域账户、SID 权限，无需虚拟 Unix 用户；
- sshd 标准 Windows 后台服务，支持开机自启、服务故障恢复；
- 原生支持 PowerShell over SSH，跨 Linux/Windows 统一远程会话；
- 日志写入 Windows 事件查看器，适配 SIEM 日志采集，解决第三方工具日志割裂问题。

行业影响

运维彻底摆脱 PuTTY 分发依赖，单台 Windows 机器开箱即可连接 Linux、网络设备；服务器可直接开启 SSH 接收远程管控，统一全栈 SSH 运维体系。

五、阶段 4：持续功能迭代（Windows 11 全版本 / Server 2022）

Windows 11 全系优化
- 客户端默认预装，终端直接调用ssh无需额外安装；
- 内置 SSH Agent 持久化密钥存储，对接 Windows 凭据管理器，无需重复输入私钥密码；
- 修复 NAT、防火墙、NTFS 路径转译兼容性 bug，支持长路径、中文目录；
- 安全更新同步上游 OpenBSD，持续淘汰弱加密算法（SHA1、1024 位 RSA）。
Windows Server 2022

维持「可选 FoD」模式，默认不安装 sshd 服务端；强化域环境、AD 组策略管控，可通过 GPO 统一推送sshd_config安全策略（禁止密码登录、限制允许登录用户）。

六、阶段 5：服务器原生预载（Windows Server 2025，2026）

颠覆性变化

服务端 sshd 系统镜像预装：系统出厂自带二进制文件，无需联网下载 FoD 包，仅需启动服务即可启用 SSH 远程管理Microsoft ...。
powershell
# Server2025无需Add-WindowsCapability，直接启动 Start-Service sshd Set-Service -Name sshd -StartupType Automatic
安全基线强化

默认配置禁用密码认证，强制公钥登录；内置密钥轮换、自动吊销弱密钥机制；原生对接 Windows 安全启动、LSA 保护。
离线运维友好

隔离内网、无 WSUS 环境无需提前缓存 FoD 安装包，大幅降低域服务器批量部署成本。

七、完整演进时间线总表

系统版本	年份	OpenSSH 状态	核心特征
Win10 1709 / Server1709	2017	Beta 预览可选功能	首版移植，bug 较多，不推荐生产
Win10 1803	2018	正式 GA（仅桌面）	移除 Beta，加密栈升级，服务器无支持
Win10 1809 / Server2019	2018	全平台标准支持	桌面 + 服务器双端可用，支持 PowerShell over SSH
Win11 21H2 ~ 24H2	2021-2025	客户端默认预装	密钥托管、凭据管理器集成、持续安全迭代
Windows Server 2022	2022	可选 FoD 组件	域 GPO 批量管控，企业安全策略完善
Windows Server 2025	2026	服务端原生预装	出厂自带 sshd，离线免安装，默认高安全基线

八、底层核心演进逻辑总结

生态统一：从私有 WinRM 走向行业标准 OpenBSD SSH，消除 Windows/Linux 运维工具割裂；
移植深度提升：从浅层兼容层，到原生适配 Windows 账户、服务、日志、组策略安全体系；
交付轻量化：客户端从需下载的可选包 → Win11 默认预装；服务端从联网 FoD → Server2025 镜像内置；
安全对齐上游：全程复用 OpenBSD LibreSSL 加密库，同步跟进 OpenSSH 官方漏洞补丁，规避自研加密栈缺陷；
运维标准化：统一 SSH 密钥、会话、传输协议，实现跨 Windows/Linux/ 网络设备一套工具完成全环境远程管理。

libssh2 完整底层拆解：架构分层｜核心逻辑链路｜SSH2 协议封装原理｜运行时序

一、基础定位

libssh2 是纯客户端侧的 SSH2 协议 C 语言实现库，只负责：客户端发起握手、密钥协商、身份认证、加密通道、Shell 执行 / SFTP 文件传输，不包含 SSH 服务端（sshd）功能。

依赖组件：OpenSSL /mbedtls（加密算法底层）、系统 socket（TCP 网络收发）、系统内存管理。

整体分层自底向上：网络层 → 传输加密层 → SSH 会话管理层 → 业务应用层（Channel/SFTP）

二、四层整体架构解构（源码目录对应模块）

1）底层网络抽象层（socket 封装）

源码文件：src/socket.c

封装系统原生 socket/connect/send/recv，屏蔽 Windows/Linux 系统网络 API 差异
提供阻塞 / 非阻塞 IO、超时控制、TCP 数据流分包重组
向上输出统一的读写接口：libssh2_send() / libssh2_recv()

作用：只负责裸 TCP 字节流收发，不解析任何 SSH 协议报文

2）SSH 传输层协议（最核心，本次 4 个漏洞全部集中在此层）

源码：transport.c、openssl.c、kex.c

对应 SSH RFC4253（SSH Transport Layer Protocol），完成握手、KEX 密钥交换、加密 / 完整性校验。

子模块拆分：

版本协商：客户端先发SSH-2.0-libssh2_xxx版本串，服务端回复对应版本
KEX 密钥交换：Diffie-Hellman/ECDH 算法协商会话密钥；本次 CVE-2026-66033、CVE-2026-66035、CVE-2026-66034 全部在 KEX 握手阶段（预认证区间）触发
加密套件绑定：协商加密算法 (AES-GCM/AES-CBC)、MAC 校验方式 (Encrypt-then-MAC)
数据包封装 / 解密：fullpacket()函数组装标准 SSH 数据包结构（长度域 + 填充 + 加密载荷 + MAC 校验值）

SSH 标准数据包结构（transport 层最小单元）

plaintext

[4字节：整个包总长度] + [1字节：填充长度] + [载荷数据] + [填充字节] + [MAC校验数据]

本次漏洞触发根源：代码对包长度数值、缓冲区分配大小校验缺失，恶意服务器构造畸形长度值 → 整数溢出 / 堆溢出 / 越界访问。

3）会话 & 认证管理层

源码：session.c、userauth.c

对应 RFC4251、RFC4252 用户认证协议

会话上下文结构体 LIBSSH2_SESSION：全局总控句柄，存放 socket 句柄、加密密钥、算法上下文、会话状态、收发缓冲区、错误码
认证方式实现：密码认证、公钥文件认证、agent 代理认证
认证状态机：未握手 → KEX 完成 → 等待认证 → 认证成功 → 会话就绪

CVE-2026-66032 属于认证完成后的 SFTP 业务层漏洞，不属于握手阶段。

4）上层业务应用层（基于 SSH Channel 通道）

SSH 建立加密链路后，依靠Channel 逻辑通道隔离不同业务数据流

Shell 通道：远程命令执行、交互式终端（channel.c）
SFTP 子系统：文件上传下载、目录操作（sftp.c，本次最高危 Double Free 漏洞所在文件sftp_open()）
端口转发（正向 / 反向代理通道）

三、完整时序逻辑链路（正常客户端连接全流程）

认证成功

libssh2_session_init 创建会话结构体

libssh2_session_handshake TCP连接服务端IP:22

socket TCP三次握手建立裸TCP连接

版本字符串交换 SSH-2.0

KEX密钥交换流程（预认证区间｜3个高危漏洞触发点）

服务端发送主机公钥

双方交换DH公开值，计算会话共享密钥

协商加密、MAC算法，初始化OpenSSL加密上下文

启用加密传输，后续所有数据全部密文传输

用户身份认证：密码/私钥校验

创建SSH逻辑Channel通道

Shell Channel：执行指令

SFTP Channel：打开sftp子系统（Double Free漏洞触发点）

G1/G2

业务数据加密收发

libssh2_session_disconnect 销毁会话、释放全部堆内存

flowchart LR
A[libssh2_session_init 创建会话结构体] --> B[libssh2_session_handshake TCP连接服务端IP:22]
B --> B1[socket TCP三次握手建立裸TCP连接]
B1 --> C[版本字符串交换 SSH-2.0]
C --> D[KEX密钥交换流程（预认证区间｜3个高危漏洞触发点）]
D --> D1[服务端发送主机公钥]
D1 --> D2[双方交换DH公开值，计算会话共享密钥]
D2 --> D3[协商加密、MAC算法，初始化OpenSSL加密上下文]
D --> E[启用加密传输，后续所有数据全部密文传输]
E --> F[用户身份认证：密码/私钥校验]
F -->|认证成功| G[创建SSH逻辑Channel通道]
G --> G1[Shell Channel：执行指令]
G --> G2[SFTP Channel：打开sftp子系统（Double Free漏洞触发点）]
G1/G2 --> H[业务数据加密收发]
H --> I[libssh2_session_disconnect 销毁会话、释放全部堆内存]

libssh2_session_init 创建会话结构体

libssh2_session_handshake TCP连接服务端IP:22

socket TCP三次握手建立裸TCP连接

版本字符串交换 SSH-2.0

KEX密钥交换流程（预认证区间｜3个高危漏洞触发点）

服务端发送主机公钥

双方交换DH公开值，计算会话共享密钥

协商加密、MAC算法，初始化OpenSSL加密上下文

启用加密传输，后续所有数据全部密文传输

用户身份认证：密码/私钥校验

创建SSH逻辑Channel通道

Shell Channel：执行指令

SFTP Channel：打开sftp子系统（Double Free漏洞触发点）

G1/G2

业务数据加密收发

libssh2_session_disconnect 销毁会话、释放全部堆内存

链路对应漏洞点位标注

D 阶段（KEX 握手、无认证）：CVE-2026-66033、34、35 三个预认证高危漏洞，恶意服务器在握手阶段即可篡改客户端内存
G2 阶段（SFTP 会话已鉴权）：CVE-2026-66032 sftp_open 双重释放，实现客户端 RCE

四、关键核心结构体解构（内存布局，漏洞利用的核心目标）

1、顶层：LIBSSH2_SESSION（全局根对象）

运行

struct _LIBSSH2_SESSION {
    int sockfd;                // TCP套接字
    LIBSSH2_TRANSPORT transport; // 传输层上下文（密钥、加密句柄）
    unsigned char *sendbuf, *recvbuf; // 收发堆缓冲区（溢出攻击目标）
    LIBSSH2_USERAUTH auth;     // 认证信息
    LIST channels;              // 所有Channel链表
    int state;                  // 会话状态机标识
    // 错误信息、超时配置、主机指纹等附属字段
}

2、传输层上下文 LIBSSH2_TRANSPORT

存储加密密钥、iv 向量、OpenSSL EVP_CIPHER_CTX、MAC 上下文，畸形数据包会破坏该结构体指针，造成内存篡改。

3、SFTP 上下文 LIBSSH2_SFTP

sftp_open()操作时会申请堆内存存放文件句柄、服务端应答数据，漏洞场景下两次调用 free () 释放同一块堆地址 → tcache double free，劫持程序执行流。

五、数据包收发底层流转细节

网络 recv 拿到原始 TCP 字节流 → transport 层按照 SSH 包格式拆分出完整 SSH 数据包
数据包送入对应处理函数：KEX 报文 → kex.c；认证报文 → userauth.c；应用数据转发至对应 Channel
向外发送数据：上层业务数据 → transport.c fullpacket () 填充包头、加密、追加 MAC 校验 → socket 发送出去

fullpacket () 正是 CVE-2026-66035 堆溢出的代码位置，包体小于加密块长度时缓冲区分配尺寸不足，memcpy 溢出堆内存。

六、内存管理机制（本次漏洞集中爆发的本质原因）

libssh2 手动管理堆内存：libssh2_malloc/libssh2_free封装系统 malloc/free

KEX 解析、公钥解析、SFTP 应答解析都会动态申请堆内存存放临时数据
异常处理分支、返回值错误路径极易出现：重复释放、释放未初始化指针、分配尺寸计算错误三大问题
Linux glibc tcache 机制下，Double Free、堆溢出可以稳定篡改堆块链表，覆写 got 表 / 函数指针，最终拿到客户端进程权限

七、libssh2 与系统 openssh（ssh 命令）本质区别

openssh（ssh 二进制）：整套客户端 + 服务端完整实现，自研加密处理逻辑；本次漏洞不影响 openssh 程序
libssh2：纯粹第三方开发的 SSH 协议开发库，给 curl、wget、自研程序、PHP、Git、各类 SFTP 工具做底层依赖；大量软件静态打包 libssh2，造成漏洞大范围扩散

八、漏洞形成的统一底层逻辑总结

libssh2 协议解析流程中，信任了远端 SSH 服务器下发的数据包长度字段，没有做严格的数值合法性校验：

传入超大数值 → 整数下溢 → memcpy 超大长度 → 进程崩溃 DoS
传入过小数据包 → 缓冲区分配不足 → 堆溢出
错误应答包 → 清理逻辑重复释放堆内存 → Double Free 远程代码执行

PixPin_2026-07-06_23-17-02

PowerShell 中运行的命令：

powershell

Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'

返回了两个条目：

Name  : OpenSSH.Client~~~~0.0.1.0
State : Installed

Name  : OpenSSH.Server~~~~0.0.1.0
State : Installed

这表明 Windows 已经将 OpenSSH 客户端和服务器作为可选功能安装好了。下面简要说明它们的意义以及如何开始使用。

1. 什么已经就绪？

组件	作用
OpenSSH.Client	提供 `ssh、scp、sftp、ssh-keygen` 等客户端工具，可从本机向远程 SSH 服务器发起连接。
OpenSSH.Server	提供 `sshd.exe` 服务（守护进程），可让其他机器通过 SSH 登录到这台 Windows 主机。

注意：仅安装了二进制文件，服务默认不会自动启动。如果想让别人能够通过 SSH 登录这台机器，还需要手动启动并（可选）设置为开机自启。

2. 快速检查客户端是否可用

在同一个 PowerShell 窗口（或 CMD）中尝试：

powershell

ssh -V
# 或
ssh user@remote-host

如果看到类似 OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3 的版本信息，说明客户端已就绪。

3. 启动并配置 OpenSSH 服务器（sshd）

3.1 启动服务

powershell

# 以管理员身份运行 PowerShell
Start-Service sshd

3.2 设置为开机自启（可选）

powershell

Set-Service -Name sshd -StartupType 'Automatic'

3.3 防火墙放行（首次安装时通常已自动处理，但可再确认）

powershell

# 确保允许入站 TCP 22 端口
New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH-Server (sshd)' `
    -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

如果您使用了第三方防火墙软件，请同样放行 22 端口。

3.4 基础验证

在同一台机器上测试本地回环连接：

powershell

ssh localhost
# 第一次连接会提示接受主机指纹，输入 yes 后根据提示输入本地账户密码（或使用密钥登录）

成功登录后会看到类似 Microsoft Windows [Version 10.0....] 的命令提示符，说明 SSH 服务器正常工作。

4. 常用配置文件位置

文件	作用
`C:\ProgramData\ssh\sshd_config`	SSHD 服务器主配置文件（修改后需重启服务）
`C:\ProgramData\ssh\ssh_config`	全局 SSH 客户端配置（可选）
`~\.ssh\authorized_keys`	每个用户的公钥授权文件（用于密钥登录）
`~\.ssh\known_hosts`	客户端保存的已信任主机指纹

编辑提示：使用记事本或 VS Code 等以 管理员 身份打开 sshd_config，否则可能没有写入权限。

常见调整项（在 `sshd_config` 中）

配置项	说明
`Port 22`	监听端口，如需改端口请修改此行并同步更新防火墙规则。
`PermitRootLogin no`	是否允许 root/Administrator 通过密码登录（建议关闭）。
`PasswordAuthentication yes`	是否允许密码登录；若想只用密钥，可设为 `no`。
`PubkeyAuthentication yes`	启用公钥认证（默认开启）。
`AllowUsers user1 user2`	白名单：仅列出的用户允许通过 SSH 登录。
`DenyUsers guest`	黑名单：被禁止登录的用户。
`Subsystem sftp sftp-server.dll`	SFTP 子系统（Windows 上使用的是 `sftp-server.dll`）。

修改完毕后重启服务：

powershell

Restart-Service sshd

5. 推荐的安全最佳实践

优先使用公钥认证，关闭密码登录：

powershell

# 在 sshd_config 中
PasswordAuthentication no
PubkeyAuthentication yes

更改默认端口（可选，增加扫描难度）：
将 Port 22 改为例如 2222，并防火墙放行新端口。
限制登录用户：使用 AllowUsers 只放行必要的账户。
定期更新：通过 Windows Update 保持 OpenSSH 组件的最新版本（微软会随系统更新同步补丁）。
审计日志：SSHD 登录事件会记录在 Windows 事件查看器 → Applications and Services Logs → OpenSSH/Operational，可设置告警。

6. 客户端使用小技巧

生成密钥对（在客户端机器上）：

powershell

ssh-keygen -t ed25519 -C "your_email@example.com"
# 生成后把公钥内容（*.pub）追加到服务器上对应用户的 %USERPROFILE%\.ssh\authorized_keys

使用 ssh-agent 缓存私钥：

powershell

# 启动代理（如果尚未运行）
Start-Service ssh-agent
# 添加私钥
ssh-add ~\.ssh\id_ed25519

SFTP 文件传输：

powershell

sftp user@windows-host
# 或在本地使用 WinSCP、FileZilla 等图形工具（协议选 SFTP，端口同上）

您的机器已经具备了完整的 OpenSSH 客户端与服务器能力。
若只需要 客户端（访问其他 Linux/Windows SSH 主机），直接使用 ssh 命令即可。
若想让这台 Windows 主机 接受远程 SSH 登录，请确保：
1. sshd 服务已启动（并可选设为自动启动）；
2. 防火墙已放行 TCP 22（或您自行设定的端口）；
3. 根据安全需求调整 sshd_config（尤其建议关闭密码登录、使用密钥认证）。

这样，您就可以像在 Linux 上一样，利用 SSH 进行安全的远程命令行、文件传输、端口转发等操作了。如果还有更具体的使用场景（比如自动化部署、Git over SSH、WSL 集成等）

在 Windows 11 上，PowerShell 提供了对 SSH （Secure Shell）安全外壳协议的支持，可以方便地安装、配置和管理 SSH 服务。Windows 11 自带了 OpenSSH （OpenBSD Secure Shell）客户端和服务端，下面是如何启用和配置它们的步骤。

1. 检查 SSH 是否已安装

Windows 11 系统默认已包含 OpenSSH （OpenBSD Secure Shell）客户端和服务器，但在某些情况下，它们可能没有启用。可以通过以下方式检查是否已安装。

打开 PowerShell 并输入以下命令：

powershellCopy Code

Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'

如果显示的结果中包含 OpenSSH.Client 和 OpenSSH.Server，则表示系统已安装这些功能。

2. 安装 OpenSSH （OpenBSD Secure Shell）客户端和服务器

如果 OpenSSH（OpenBSD Secure Shell）组件没有安装，您可以通过 PowerShell 安装它们。

安装 OpenSSH（OpenBSD Secure Shell）客户端

powershellCopy Code

Add-WindowsCapability -Online -Name OpenSSH.Client

安装 OpenSSH（OpenBSD Secure Shell）服务器

powershellCopy Code

Add-WindowsCapability -Online -Name OpenSSH.Server

3. 启用并启动 SSH （Secure Shell）安全外壳协议服务

安装完成后，您需要启动 SSH （Secure Shell）安全外壳协议服务并配置为自动启动。

启动 OpenSSH（OpenBSD Secure Shell）服务

powershellCopy Code

Start-Service sshd

设置 SSH （Secure Shell）安全外壳协议服务在启动时自动启动

powershellCopy Code

Set-Service -Name sshd -StartupType 'Automatic'

4. 配置防火墙允许 SSH （Secure Shell）安全外壳协议流量

默认情况下，Windows 防火墙可能会阻止 SSH （Secure Shell）安全外壳协议流量。可以通过以下命令允许 SSH （Secure Shell）安全外壳协议流量：

powershellCopy Code

New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Protocol TCP -Action Allow -LocalPort 22

5. 配置 SSH （Secure Shell）安全外壳协议服务器

编辑 `sshd_config` 文件

SSH （Secure Shell）安全外壳协议配置文件通常位于 C:\ProgramData\ssh\sshd_config。您可以使用文本编辑器打开并编辑该文件。

例如，使用 PowerShell 编辑器（例如 notepad）打开文件：

powershellCopy Code

notepad C:\ProgramData\ssh\sshd_config

在该文件中，您可以配置 SSH （Secure Shell）安全外壳协议服务的各种选项，如禁用密码登录、配置公钥认证等。

重新启动 SSH （Secure Shell）安全外壳协议服务

如果您对配置文件进行了更改，需要重新启动 SSH （Secure Shell）安全外壳协议服务来应用更改：

powershellCopy Code

Restart-Service sshd

6. 使用 SSH 客户端连接到远程主机

Windows 11 自带的 OpenSSH（OpenBSD Secure Shell）客户端可以用于通过 SSH （Secure Shell）安全外壳协议连接到远程服务器。在 PowerShell 中使用以下命令连接到远程主机：

powershellCopy Code

ssh username@hostname

替换 username 和 hostname 为您要连接的远程主机的用户名和 IP 地址或主机名。

7. 配置 SSH （Secure Shell）安全外壳协议密钥认证（可选）

如果您希望通过SSH （Secure Shell）安全外壳协议密钥进行认证而不是密码，可以生成 SSH （Secure Shell）安全外壳协议密钥对并将公钥添加到远程服务器的 ~/.ssh/authorized_keys 文件中。

生成 SSH （Secure Shell）安全外壳协议密钥对

在 PowerShell 中运行以下命令：

powershellCopy Code

ssh-keygen

然后按照提示生成密钥对。默认情况下，密钥将保存在 C:\Users\<YourUserName>\.ssh\id_rsa。

将公钥添加到远程服务器

将公钥文件内容复制到远程主机的 ~/.ssh/authorized_keys 文件中：

powershellCopy Code

type $env:USERPROFILE\.ssh\id_rsa.pub | ssh username@hostname "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

这样您就可以通过密钥认证连接到远程主机。

通过以上步骤，您就可以在 Windows 11 上成功启用并配置 SSH （Secure Shell）安全外壳协议服务。

SSH 自研协议栈完整清单（区分：协议报文逻辑自研 / 仅密码算法依赖第三方密码库；完全从零编写 RFC4251~4254 报文解析、握手状态机、通道、SFTP）

先明确界定标准：

✅ 真正自研协议栈：自己写 SSH 数据包封装解析、KEX 状态机、认证流程、Channel 多路复用、SFTP 协议；仅借用 OpenSSL/ring 做底层数学加解密运算

❌ 不算自研：直接封装 libssh /libssh2 /ssh2 库（WindTerm、Electerm、Xshell、FinalShell 全都属于这类）

一、C 语言经典老牌自研 SSH 协议栈（最常用）

1、PuTTY（最知名纯自研）

协议层：全套 SSH-1/SSH-2 协议全自研实现（ssh.c、sshtrans.c、sshkex.c、sshchan.c 手写完整状态机、报文组包解包、MAC 校验、通道转发、X11 转发、Agent 协议）
密码：仅调用 OpenSSL 做 AES、ECC、哈希数学运算，协议逻辑无第三方 SSH 库依赖
配套：pscp、psftp、plink、pageant 整套体系全部自主实现
授权：MIT，源码干净，攻击面小，安全审计友好
衍生分支：KiTTY、PuTTY Tray 均沿用原生自研协议栈

2、OpenSSH（服务端 sshd + 客户端 ssh，行业事实标准）

协议栈完全自研，SSH 全套报文、握手、连接管理自主编码
底层加密依托 OpenSSL，协议框架无外部 SSH 库
Linux/macOS 系统默认 SSH 程序，服务器端最主流实现

3、libssh（注意和 libssh2 区分）

C 语言独立自研 SSH 全协议栈（客户端 + 服务端双向支持），不基于 OpenSSH 源码二次封装
支持端口转发、SFTP、SCP、Agent、GSSAPI
多用于嵌入式、网关设备、自研运维平台开发

二、各编程语言生态纯自研 SSH 库

Rust（现代无内存安全问题，近年主流自研选型）

russh

纯 Rust 手写 SSH2 全协议，客户端 + 服务端双支持，搭配 ring 密码库；OxideTerm 终端底层就是 russh 自研栈，无任何 C 语言 SSH 绑定
puressh

从零实现 SSH 报文格式、MP 整数、KEX 协商，全链路 Rust 原生实现
qssh

自研 SSH 协议 + 内置后量子加密算法，带形式化数学证明，高安全场景使用

Java 生态纯自研（无本地 C 库依赖）

JSch

纯 Java 手写完整 SSH2 协议栈，不调用任何本地 OpenSSL/libssh；老牌 Java 自动化、Jenkins、Ant 底层标配
sshj

新一代纯 Java 自研 SSH，原生支持 ChaCha20、Ed25519，异步非阻塞设计

JavaScript / TypeScript 纯自研

ssh2（node-ssh2）

完全 JS 实现 SSH 全部协议规范，TCP 之上自主处理数据包分片、密钥交换、Channel、SFTP；Electerm、webssh 网页终端大量基于此自研 JS 协议栈

Python

Paramiko

纯 Python 代码实现 SSH-2 整套协议逻辑，加密调用 cryptography 库，协议本体完全自研；Python 运维、堡垒机最普遍方案

C# / .NET

SSH.NET

托管代码从零实现 SSH 协议，无 libssh2 封装，原生.NET 全托管自研栈

三、闭源商用软件自研协议栈（付费终端）

SecureCRT / SecureFX：VanDyke 公司内部全套自研 SSH 协议栈，不开源，安全性自主可控
Bitvise SSH Client：Windows 知名工具，自研 SSH 协议 + 自研虚拟网卡端口转发体系

四、国产自主可控改造型自研 SSH（国密适配）

GMSSH、GMClaw：基于标准 SSH RFC 框架自研协议逻辑，将原版国际算法替换为 SM2/SM3/SM4 国密套件，政企等保场景专用
部分军工 / 网关自研 SSH：剥离 OpenSSL，搭配国产商用密码库实现全套加密链路自主化

五、一张区分表：自研协议栈 VS 封装第三方库（高频软件对照）

软件	SSH 实现方式	归类
PuTTY、OpenSSH	协议全自研，仅依赖密码库	自研协议栈
WindTerm、MobaXterm、FinalShell	基于 libssh2 封装	封装第三方库（非自研）
Xshell、CRT、Bitvise	闭源内部自研	商业自研栈
Electerm、Tabby	Node.js ssh2 库封装	封装库
Paramiko、JSch、russh	语言原生手写协议	开源自研库

六、自研协议栈优缺点总结

优势

无第三方 SSH 库供应链漏洞（libssh2 近期爆发多枚高危 RCE 漏洞，自研不受牵连）
报文解析逻辑可控，可自定义私有扩展、私有安全校验规则
深度适配特殊网络环境：弱网、代理多层跳转、自定义心跳保活
等保、涉密场景可完成全代码审计

劣势

开发工作量极大，RFC4251~4254 整套状态机极易写出内存越界、数据包解析漏洞；长期维护加密算法迭代成本高

自研 SSH‑2 协议栈分层开发学习路线

依据 RFC4251 (总体架构)、RFC4253 (传输层 / KEX)、RFC4252 (用户认证)、RFC4254 (连接通道)、RFC4256 (交互式键盘认证)、RFC4288 (SFTP v3)

层级顺序：TCP 传输层 → SSH 传输协议层 (KEX 密钥交换) → 用户认证层 → Channel 多路复用层 → 上层子系统 (SFTP/Shell/ 端口转发 / X11)

前置基础：TCP 网络编程、大端网络字节序、ASN.1 公钥解析、Diffie‑Hellman/ECDH、HMAC、AES‑GCM/ChaCha20；会抓包 Wireshark 解析 SSH 报文。

重要提醒：不要直接上来写代码，先抓包观察真实 OpenSSH/PuTTY 完整交互流程。

阶段 0：前置准备（基础储备）

熟读 RFC4251，理解整体四层模型
Wireshark 过滤 ssh，抓取完整握手全流程：版本协商→KEX_INIT→KEX_ECDH_INIT→NEW_KEYS→认证请求→channel_open→shell
工具准备
- 抓包：Wireshark，开启 SSH 解密（可选导入服务器私钥解密流量）
- 参考实现阅读：PuTTY 源码、russh (Rust)、Paramiko (Python)
- 测试服务端：OpenSSH‑sshd 本地虚拟机作为被测服务端，自己写的客户端与之互通

SSH‑2 整体分层模型

plaintext

应用层：Shell / SFTP / SCP / 端口转发 / X11
↑
Channel多路复用层 RFC4254
↑
用户认证协议 RFC4252
↑
SSH传输层协议 RFC4253（版本协商、KEX、加密报文、压缩）
↑
TCP套接字（字节流，无边界）

阶段 1：TCP 传输层 + SSH 版本字符串协商（最底层）

RFC：RFC4253 Section 4.2

目标：完成 TCP 连接，收发 SSH 版本字符串；实现 TCP 字节流分包，把 TCP 字节流切割成 SSH 数据包边界。

知识点

TCP 是字节流，没有包边界；SSH 每个数据包前 4 字节大端packet_length，这是数据包分界。
版本字符串格式示例：SSH‑2.0‑MyCustomStack‑0.1\r\n（明文发送，未加密）
服务端返回版本字符串；双方比对主版本必须等于 2，不兼容 SSH‑1。

开发任务清单

建立 TCP Socket 连接服务端 22 端口
发送客户端版本字符串；读取服务端版本字符串

实现 SSH 数据包帧解析器

plaintext

uint32 packet_length   // 不包含自身4字节
uint8  padding_length
byte[] payload
byte[] padding
byte[] mac（如果不是Encrypt‑then‑MAC模式）

处理粘包：缓冲区持续读字节，凑够packet_length+4才取出一个完整包。

⚠️坑：版本字符串是明文，版本协商完成之后，后面所有数据包全部加密。

阶段 1 验收标准：可以成功拿到服务端版本号，能够从 TCP 流切分出完整 SSH 原始数据包。

阶段 2：SSH 传输协议层 — KEX 密钥交换 RFC4253 Section 7‑8

整个 KEX 全部是未加密报文；收到SSH_MSG_NEWKEYS之后，后续全部报文启用加密 + MAC。

报文顺序（标准 ECDH KEX 流程）

客户端发送 SSH_MSG_KEX_INIT：发送自己支持的算法列表
- KEX 算法列表、加密算法 (cipher)、MAC 算法、压缩算法
服务端回复 SSH_MSG_KEX_INIT，协商选出一套共同支持算法
客户端发送 SSH_MSG_KEX_ECDH_INIT：客户端临时 ECDH 公钥
服务端回复 SSH_MSG_KEX_ECDH_REPLY：
- 服务端主机公钥（host‑key）
- 服务端临时 ECDH 公钥
- 整个 KEX 哈希签名（用来校验服务端身份，防止中间人）
双方计算 ECDH 共享秘密K；计算 KEX 哈希 H；从 (K,H) 派生 6 组会话密钥：

客户端→服务端：加密 key、IV、MAC key

服务端→客户端：加密 key、IV、MAC key
客户端发送 SSH_MSG_NEWKEYS
服务端回复 SSH_MSG_NEWKEYS

✅ 自此，之后所有数据包全部开启加密、完整性校验。

关键开发点

实现 ECDH 密钥协商；处理多种 KEX 算法：curve25519‑sha256@libssh.org、nistp256
解析服务端 Host‑Key（RSA/ED25519 公钥 blob），验签 KEX 哈希 H（防中间人攻击）
密钥派生函数 KDF；6 套会话密钥分开，收发方向密钥不能混用
实现两种加密模式：MAC‑then‑Encrypt / Encrypt‑then‑MAC（libssh2 漏洞就出在 EtM 报文解析）
数据包加密、解密；MAC 校验；解密失败直接断开连接。

坑点

很多新手收发方向密钥混用，直接报 MAC 错误断开。
Host‑Key 主机密钥校验逻辑，要保存 known_hosts，识别陌生主机。

阶段 2 验收标准：完成 KEX 握手，成功进入加密会话，能够收发加密 SSH_MSG 消息。

阶段 3 用户认证协议 RFC4252 User‑auth

KEX 完成加密通道之后进入认证层；通道还没有登录成功。

报文流程：

客户端发送 SSH_MSG_USERAUTH_REQUEST，携带用户名 + 认证方法（password /publickey/keyboard‑interactive）
服务端返回 SSH_MSG_USERAUTH_FAILURE：返回支持的剩余认证方式
循环选择认证方式重试；
收到 SSH_MSG_USERAUTH_SUCCESS → 认证成功，进入 Channel 层

需要实现三种主流认证

密码认证 password
公钥认证 publickey：本地私钥签名认证数据包；支持 RSA、Ed25519 私钥解析
键盘交互 keyboard‑interactive（二次验证码 MFA） RFC4256

开发任务

解析 OpenSSH 格式私钥文件（PEM/openssh‑new 格式）
对 userauth 数据包做私钥签名
处理部分成功认证，多因素交互逻辑

坑：公钥认证分为两阶段：先试探，再真正签名请求，很多实现在这里出错。

阶段 3 验收：用户名密码或者密钥登录成功，收到 USERAUTH_SUCCESS。

阶段 4 Channel 多路复用层 RFC4254（最复杂核心）

SSH 单条 TCP 加密连接之上，多路复用多个独立逻辑 Channel，每个 Channel 有本地 id / 远端 id。

Shell 终端、SFTP、端口转发，全部是不同的 Channel。

核心报文

SSH_MSG_CHANNEL_OPEN：申请打开某一类 Channel
- channel‑type：session（shell 命令） / direct‑tcp‑ip(正向端口转发) / x11
SSH_MSG_CHANNEL_OPEN_CONFIRMATION：服务端返回打开成功；分配远端 channel id
SSH_MSG_CHANNEL_DATA：普通标准输出数据
SSH_MSG_CHANNEL_EXTENDED_DATA：stderr 标准错误输出
SSH_MSG_CHANNEL_WINDOW_ADJUST：流量窗口控制（极其重要！）
SSH_MSG_CHANNEL_CLOSE 关闭通道

⚠️重点难点：SSH 滑动窗口流量控制 Window‑Adjust

服务端不能无限发送数据；当客户端接收缓冲区剩余空间变小，发送 WINDOW_ADJUST 通知服务端增加窗口；不实现窗口调节，大输出会卡死、丢数据。

常见 Channel 类型

session：执行 shell 交互、执行单条命令 exec、启动 sftp 子系统
direct‑tcp‑ip：本地端口转发
forwarded‑tcp‑ip：远程反向端口转发

开发任务

Channel 管理器：维护 ChannelID 映射表，多个 channel 并发管理
实现 Window 窗口流量控制逻辑
处理 DATA / EXTENDED_DATA，分离 stdout/stderr
Channel 关闭、销毁资源回收

阶段 4 验收：打开 session channel，拿到交互式 Shell 输出，键盘输入可以下发到服务器。

阶段 5：上层子系统（基于 Channel 之上）

5‑1 Shell / Exec 命令执行

channel‑open type=session，发送 SSH_MSG_CHANNEL_REQUEST want_reply=true，请求shell或者exec "command"
接收 channel_data 输出；把用户输入封装成 channel_data 发送。

5‑2 SFTP 子系统 RFC4283 SFTP‑v3

SFTP 跑在 session channel 内部；请求子系统 sftp，之后全部是 SFTP 二进制报文，不再是 SSH_MSG 消息。

SFTP 独立二进制协议：

SSH 通道建立成功后发送：subsystem sftp 请求
之后收发：SSH_MSG_CHANNEL_DATA 里面承载 SFTP 数据包
实现：SSH_FXP_INIT / SSH_FXP_OPENDIR / READDIR / OPEN / READ / WRITE / REMOVE / STAT 等

坑：区分 SSH 协议消息和 SFTP 子消息，两层报文嵌套，非常容易混淆。

5‑3 端口转发 direct‑tcp‑ip /forwarded‑tcp‑ip

本地端口转发：客户端打开direct‑tcp‑ip类型 channel，指定目标主机端口。

5‑4 Agent 转发、X11 转发（拓展选做）

阶段 5 验收：可执行 shell 命令；可 ls/get/put 完成 SFTP 上传下载。

阶段 6：健壮性、高级特性、漏洞加固（生产级别）

保活机制：SSH_MSG_IGNORE心跳，检测僵死 TCP 连接
压缩zlib@openssh.com
ProxyJump 跳板机链式连接
known_hosts 主机密钥管理，防中间人
报文边界、长度校验，防止恶意超大数据包；防止整数溢出
各类异常处理：KEX 失败、认证失败、channel 关闭、TCP 断连资源释放

开发避坑清单（高频踩坑）

字节序：全部字段大端网络字节序，各种 u32/u64 极易搞错。
收发两套独立加密密钥，不能共用。
Window‑Adjust 窗口流量控制不做，大输出直接卡死。
两层报文嵌套：SSH 传输包内部承载 Channel；Channel‑data 内部承载 SFTP 二进制报文。
KEX 签名校验 Host‑Key，跳过验签直接完全没有安全意义。
EtM（Encrypt‑then‑MAC）模式 MAC 计算对象，不要和 MtE 搞混（libssh2 历史漏洞点）。

posted @ 2025-01-29 01:37 suv789 阅读(6725) 评论(0) 收藏举报

刷新页面返回顶部

suv789

Windows 内置 OpenSSH（OpenBSD Secure Shell）完整演进历程

一、前置阶段：无原生 SSH 时代（Windows XP ~ Windows 10 1703）

生态痛点

底层背景

二、阶段 1：Beta 预览版落地（Windows 10 1709 / Server 1709，2017 秋）

三、阶段 2：正式 GA 商用可用（Windows 10 1803，2018 春）

四、阶段 3：全平台标准化预装（Windows 10 1809 / Server 2019，2018 冬，里程碑版本）

核心突破：客户端、服务端全产品线全系统正式支持

行业影响

五、阶段 4：持续功能迭代（Windows 11 全版本 / Server 2022）

六、阶段 5：服务器原生预载（Windows Server 2025，2026）

颠覆性变化

七、完整演进时间线总表

八、底层核心演进逻辑总结

libssh2 完整底层拆解：架构分层｜核心逻辑链路｜SSH2 协议封装原理｜运行时序

一、基础定位

二、四层整体架构解构（源码目录对应模块）

1）底层网络抽象层（socket 封装）

2）SSH 传输层协议（最核心，本次 4 个漏洞全部集中在此层）

3）会话 & 认证管理层

4）上层业务应用层（基于 SSH Channel 通道）

三、完整时序逻辑链路（正常客户端连接全流程）

链路对应漏洞点位标注

四、关键核心结构体解构（内存布局，漏洞利用的核心目标）

1、顶层：LIBSSH2_SESSION（全局根对象）

2、传输层上下文 LIBSSH2_TRANSPORT

3、SFTP 上下文 LIBSSH2_SFTP

五、数据包收发底层流转细节

六、内存管理机制（本次漏洞集中爆发的本质原因）

七、libssh2 与系统 openssh（ssh 命令）本质区别

八、漏洞形成的统一底层逻辑总结

1. 什么已经就绪？

2. 快速检查客户端是否可用

3. 启动并配置 OpenSSH 服务器（sshd）

3.1 启动服务

3.2 设置为开机自启（可选）

3.3 防火墙放行（首次安装时通常已自动处理，但可再确认）

3.4 基础验证

4. 常用配置文件位置

常见调整项（在 sshd_config 中）

5. 推荐的安全最佳实践

6. 客户端使用小技巧

1. 检查 SSH 是否已安装

2. 安装 OpenSSH （OpenBSD Secure Shell）客户端和服务器

安装 OpenSSH（OpenBSD Secure Shell） 客户端

安装 OpenSSH（OpenBSD Secure Shell） 服务器

3. 启用并启动 SSH （Secure Shell）安全外壳协议 服务

启动 OpenSSH（OpenBSD Secure Shell）服务

设置 SSH （Secure Shell）安全外壳协议 服务在启动时自动启动

4. 配置防火墙允许 SSH （Secure Shell）安全外壳协议 流量

5. 配置 SSH （Secure Shell）安全外壳协议 服务器

编辑 sshd_config 文件

重新启动 SSH （Secure Shell）安全外壳协议 服务

6. 使用 SSH 客户端连接到远程主机

7. 配置 SSH （Secure Shell）安全外壳协议 密钥认证（可选）

生成 SSH （Secure Shell）安全外壳协议密钥对

将公钥添加到远程服务器

SSH 自研协议栈完整清单（区分：协议报文逻辑自研 / 仅密码算法依赖第三方密码库；完全从零编写 RFC4251~4254 报文解析、握手状态机、通道、SFTP）

一、C 语言经典老牌自研 SSH 协议栈（最常用）

1、PuTTY（最知名纯自研）

2、OpenSSH（服务端 sshd + 客户端 ssh，行业事实标准）

3、libssh（注意和 libssh2 区分）

二、各编程语言生态 纯自研 SSH 库

Rust（现代无内存安全问题，近年主流自研选型）

Java 生态纯自研（无本地 C 库依赖）

JavaScript / TypeScript 纯自研

Python

C# / .NET

三、闭源商用软件自研协议栈（付费终端）

四、国产自主可控改造型自研 SSH（国密适配）

五、一张区分表：自研协议栈 VS 封装第三方库（高频软件对照）

六、自研协议栈优缺点总结

优势

劣势

自研 SSH‑2 协议栈分层开发学习路线

阶段 0：前置准备（基础储备）

阶段 1：TCP 传输层 + SSH 版本字符串协商（最底层）

知识点

开发任务清单

常见调整项（在 `sshd_config` 中）

安装 OpenSSH（OpenBSD Secure Shell）客户端

安装 OpenSSH（OpenBSD Secure Shell）服务器

3. 启用并启动 SSH （Secure Shell）安全外壳协议服务

设置 SSH （Secure Shell）安全外壳协议服务在启动时自动启动

4. 配置防火墙允许 SSH （Secure Shell）安全外壳协议流量

5. 配置 SSH （Secure Shell）安全外壳协议服务器

编辑 `sshd_config` 文件

重新启动 SSH （Secure Shell）安全外壳协议服务

7. 配置 SSH （Secure Shell）安全外壳协议密钥认证（可选）

二、各编程语言生态纯自研 SSH 库