[!NOTE] SSH3 可能会更改名称。它仍然是运行在 HTTP/3 扩展连接之上的 SSH 连接协议 (RFC4254)，但所需的更改非常重大，且与流行 SSH 实现的设计理念相距甚远，因此难以考虑集成。规范草案已经重命名为 "Remote Terminals over HTTP/3"，但我们需要一些时间来想出一个好听的永久名称。

SSH3: 使用 HTTP/3 实现更快、更丰富的安全 Shell

SSH3 是对 SSH 协议的彻底重新审视，将其语义映射到 HTTP 机制之上。它源自我们的研究工作，我们（研究人员）最近将其作为 Internet-Draft (draft-michel-remote-terminal-http3-00) 提出。

简而言之，SSH3 使用 QUIC+TLS1.3 进行安全通道建立，并使用 HTTP 授权机制进行用户认证。除此之外，SSH3 还实现了以下改进：

• 显著更快的会话建立
• 新的 HTTP 认证方法，例如 OAuth 2.0 和 OpenID Connect，以及经典的 SSH 认证
• 对端口扫描攻击的鲁棒性：您的 SSH3 服务器可以被设置为对互联网其他用户不可见
• 除了经典的 TCP 端口转发外，还支持 UDP 端口转发
• 现代 QUIC 协议允许的所有功能：包括连接迁移（即将推出）和多路径连接

[!TIP] 想快速开始？查看如何安装 SSH3。您将学习设置 SSH3 服务器并使用 SSH3 客户端。

⚡ SSH3 速度更快

更快的是会话建立，而不是吞吐量！SSH3 相比 SSHv2 提供了显著更快的会话建立。使用 SSHv2 建立新会话需要 5 到 7 个网络往返时间，用户很容易感觉到延迟。SSH3 只需要 3 个往返时间。运行中的会话击键延迟保持不变。

SSH3 (顶部) 对比 SSHv2 (底部) 在服务器 ping 延迟为 100ms 时的会话建立过程。

🔒 SSH3 安全性

虽然 SSHv2 定义了自身的用户认证和安全通道建立协议，但 SSH3 依赖于 TLS 1.3、QUIC 和 HTTP 这些稳健且经过时间考验的机制。这些协议已被广泛用于保护互联网上的安全关键型应用，例如电子商务和网上银行。

SSH3 已经实现了常见的基于密码和公钥（RSA 和 EdDSA/ed25519）的认证方法。它还支持新的认证方法，如 OAuth 2.0，并允许使用您的 Google/Microsoft/Github 账户登录服务器。

🧪 SSH3 仍处于实验阶段

虽然 SSH3 在更快的会话建立方面显示出潜力，但它仍处于早期的概念验证阶段。与任何新的复杂协议一样，在得出合理的安全结论之前，需要经过长时间的专家密码学审查。

我们正在将 SSH3 作为一个开源项目进行开发，以促进社区反馈和分析。然而，在未经进一步同行评审的情况下，我们尚不能认可其适用于生产系统。如果您有相关专业知识，请与我们合作！

🥷 目前请勿将 SSH3 服务器部署到生产服务器

鉴于当前的原型状态，我们建议在沙盒环境或私有网络中测试 SSH3。请注意，在彻底的安全审查之前，将实验性服务器直接暴露在互联网上可能会带来风险。

虽然将服务器隐藏在秘密路径之后有潜在的好处，但这并不能否定在生产环境之前进行严格漏洞分析的必要性。我们对 SSH3 的未来前景感到兴奋，但鼓励先进行额外的审查。

🥷 您的 SSH3 公共服务器可以隐藏

使用 SSH3，您可以避免针对 SSH 服务器的常见扫描和字典攻击压力。类似于您的秘密 Google Drive 文档，您的 SSH3 服务器可以隐藏在一个秘密链接后面，并且只响应针对该特定链接的 HTTP 请求的认证尝试，如下所示：

ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>

通过将 <my-long-secret> 替换为，例如，随机值 M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU，您的 SSH3 服务器将仅响应针对 URL https://192.0.2.0:443/M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU 的 SSH3 连接尝试，而对其他请求返回 404 Not Found。因此，互联网上的攻击者和爬虫无法检测到您 SSH3 服务器的存在。它们只会看到一个简单的 Web 服务器，对每个请求都返回 404 状态码。

请注意：将 SSH3 服务器放在秘密 URL 后面可能会减少扫描攻击的影响，但不会也绝不能*替代传统的认证机制。秘密链接应仅用于避免您的主机被发现。知道秘密 URL 不应授予任何人访问您服务器的权限。请使用上述描述的传统认证机制来保护您的服务器。

💐 SSH3 已经功能丰富

SSH3 提供了 SSHv2 协议无法提供的新功能。

全新功能

• UDP 端口转发：您现在可以访问仅能从 SSH3 主机到达的 QUIC、DNS、RTP 或任何基于 UDP 的服务器。UDP 数据包通过 QUIC 数据报进行转发。
• X.509 证书：您现在可以使用传统的 HTTPS 证书来验证您的 SSH3 服务器。此机制比传统的 SSHv2 主机密钥机制更安全。例如，可以轻松使用 LetsEncrypt 获取证书。
• 将服务器隐藏在秘密链接后面。
• 使用 OpenID Connect 实现免密钥的安全用户认证。您可以使用公司的 SSO 或您的 Google/Github 账户连接到您的 SSH3 服务器，不再需要复制用户的公钥。

已实现的著名 OpenSSH 功能

此 SSH3 实现已经提供了许多 OpenSSH 的流行功能，因此如果您习惯使用 OpenSSH，采用 SSH3 的过程将很顺利。以下是 SSH3 也实现的一些 OpenSSH 功能列表：

• 在服务器端解析 ~/.ssh/authorized_keys
• 基于证书的服务器认证
• 当不使用 X.509 证书时的 known_hosts 机制
• 自动使用 ssh-agent 进行公钥认证
• SSH 代理转发，在远程服务器上使用您的本地密钥
• 直接 TCP 端口转发（反向端口转发将在未来实现）
• 代理跳转（参见 -proxy-jump 参数）。如果 A 是 SSH3 客户端，B 和 C 都是 SSH3 服务器，您可以使用 B 作为网关/代理从 A 连接到 C。代理使用 UDP 转发将 QUIC 数据包从 A 转发到 C，因此 B 无法解密 A<->C 的 SSH3 流量。
• 在客户端解析 ~/.ssh/config，并处理 Hostname、User、Port 和 IdentityFile 配置选项（其他选项目前被忽略）。还解析一个新的 UDPProxyJump，其行为类似于 OpenSSH 的 ProxyJump。

🙏 社区支持

帮助我们负责任地推进 SSH3！我们欢迎有能力的安全研究人员审查我们的代码库并提供反馈。也请帮助我们联系相关标准机构，以便随着时间的推移可能通过正式的 IETF/IRTF 流程推进 SSH3。

通过协作帮助，我们希望迭代改进 SSH3，使其达到安全的生产就绪状态。但在没有广泛专家密码学审查和受尊敬的安全机构采纳的证据之前，我们无法可信地做出明确的安全声明。让我们一起努力实现 SSH3 的可能性！

安装 SSH3

您可以下载最新的发布版二进制文件， 使用 go install 安装它，或者通过从源代码编译自行生成这些二进制文件。

[!TIP] SSH3 仍处于实验阶段，是研究工作的成果。如果您担心公开部署新的 SSH3 服务器，您可以使用 SSH3 的 秘密路径 功能将其隐藏在秘密 URL 后面。

使用 Go install 安装 ssh3 和 ssh3-server

go install github.com/francoismichel/ssh3/cmd/...@latest

从源代码编译 SSH3

您需要最新的 Golang 版本来执行此操作。可以通过以下步骤下载源代码并编译二进制文件：

git clone https://github.com/francoismichel/ssh3    # clone the repo
cd ssh3
go build -o ssh3 cmd/ssh3/main.go                        # build the client
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go   # build the server, requires having gcc installed

如果您有 root/sudo 权限，并且希望让所有用户都能使用 ssh3，则可以直接将二进制文件复制到 /usr/bin：

cp ssh3 /usr/bin/ && cp ssh3-server /usr/bin

否则，您可以通过在 .bashrc 或等效文件末尾添加以下行来简单地将可执行文件添加到 PATH 环境变量：

export PATH=$PATH:/path/to/the/ssh3/directory

部署 SSH3 服务器

在连接到您的主机之前，您需要在其上部署 SSH3 服务器。目前还没有 SSH3 守护进程，因此现在您需要使用 screen 或类似工具在后台运行 ssh3-server 可执行文件。

[!NOTE] 由于 SSH3 运行在 HTTP/3 之上，服务器需要一个 X.509 证书及其对应的私钥。可以通过在服务器上使用 -generate-public-cert 命令行参数，通过 Let's Encrypt 为您的公共域名自动生成公共证书。如果您不想生成由真实证书颁发机构签名的证书，或者您没有任何公共域名，您可以使用 -generate-selfsigned-cert 命令行参数生成自签名证书。自签名证书为您提供类似于 SSHv2 主机密钥机制的安全保障，并具有相同的安全问题：在您首次连接到服务器时，可能容易受到中间人攻击。使用由公共证书颁发机构（如 Let's Encrypt）签名的真实证书可以避免此问题。

以下是 ./ssh3-server 可执行文件的用法：

Usage of ./ssh3-server:
  -bind string
        the address:port pair to listen to, e.g. 0.0.0.0:443 (default "[::]:443")
  -cert string
        the filename of the server certificate (or fullchain) (default "./cert.pem")
  -key string
        the filename of the certificate private key (default "./priv.key")
  -enable-password-login
        if set, enable password authentication (disabled by default)
  -generate-public-cert value
        Automatically produce and use a valid public certificate usingLet's Encrypt for the provided domain name. The flag can be used several times to generate several certificates.If certificates have already been generated previously using this flag, they will simply be reused without being regenerated. The public certificates are automatically renewed as long as the server is running. Automatically-generated IP public certificates are not available yet.
  -generate-selfsigned-cert
        if set, generates a self-self-signed cerificate and key that will be stored at the paths indicated by the -cert and -key args (they must not already exist)
  -url-path string
        the secret URL path on which the ssh3 server listens (default "/ssh3-term")
  -v    verbose mode, if set
  -version
        if set, displays the software version on standard output and exit

以下命令在 443 端口上启动一个公共 SSH3 服务器，使用针对域 my-domain.example.org 的有效 Let's Encrypt 公共证书，并响应查询 /ssh3 URL 路径的新会话请求：

ssh3-server -generate-public-cert my-domain.example.org -url-path /ssh3

如果您没有公共域名（即只有一个 IP 地址），您可以使用 -cert 和 -key 参数使用针对您的 IP 地址的现有证书，或使用 -generate-selfsigned-cert 参数生成自签名证书。

如果您有现有的证书和密钥，您可以按如下方式运行服务器以使用它们：

ssh3-server -cert /path/to/cert/or/fullchain -key /path/to/cert/private/key -url-path /ssh3

[!NOTE] 与 OpenSSH 类似，服务器必须以 root 权限运行才能以其他用户身份登录。

授权密钥和授权身份

默认情况下，SSH3 服务器将在每个用户的 ~/.ssh/authorized_keys 和 ~/.ssh3/authorized_identities 文件中查找身份。 ~/.ssh3/authorized_identities 允许新的身份，例如下面讨论的 OpenID Connect (oidc)。 可以使用流行的密钥类型，例如 rsa、ed25519 和 OpenSSH 格式的密钥。

使用 SSH3 客户端

一旦您有一个 SSH3 服务器正在运行，您就可以像使用传统的 SSHv2 工具一样，使用 SSH3 客户端连接到它。

以下是 ssh3 可执行文件的用法：

Usage of ssh3:
  -pubkey-for-agent string
        if set, use an agent key whose public key matches the one in the specified path
  -privkey string
        private key file
  -use-password
        if set, do classical password authentication
  -forward-agent
        if set, forwards ssh agent to be used with sshv2 connections on the remote host
  -forward-tcp string
        if set, take a localport/remoteip@remoteport forwarding localhost@localport towards remoteip@remoteport
  -forward-udp string
        if set, take a localport/remoteip@remoteport forwarding localhost@localport towards remoteip@remoteport
  -proxy-jump string
    	if set, performs a proxy jump using the specified remote host as proxy
  -insecure
        if set, skip server certificate verification
  -keylog string
        Write QUIC TLS keys and master secret in the specified keylog file: only for debugging purpose
  -use-oidc string
        if set, force the use of OpenID Connect with the specified issuer url as parameter
  -oidc-config string
        OpenID Connect json config file containing the "client_id" and "client_secret" fields needed for most identity providers
  -do-pkce
        if set, perform PKCE challenge-response with oidc
  -v    if set, enable verbose mode

私钥认证

您可以使用位于 ~/.ssh/id_rsa 的私钥，通过以下命令连接到在 my-server.example.org 上监听 /my-secret-path 的 SSH3 服务器：

  ssh3 -privkey ~/.ssh/id_rsa [email protected]/my-secret-path

基于代理的私钥认证

SSH3 客户端与 OpenSSH 代理配合使用，并使用传统的 SSH_AUTH_SOCK 环境变量与该代理通信。与 OpenSSH 类似，SSH3 会列出 SSH 代理提供的密钥，并默认使用代理列出的第一个密钥进行连接。 如果您想指定与代理一起使用的特定密钥，您可以直接使用 -privkey 参数指定私钥（如上所述），或者使用 -pubkey-for-agent 参数指定相应的公钥。这在以下情况下很有用：只有代理能直接访问私钥，而您只能访问公钥。

基于密码的认证

虽然不鼓励，但您可以使用密码连接到您的服务器（如果在 ssh3-server 上明确启用了密码认证），命令如下：

  ssh3 -use-password [email protected]/my-secret-path

基于配置的会话建立

ssh3 解析您的 OpenSSH 配置。目前，它仅处理 Hostname；User、Port 和 IdentityFile 这些 OpenSSH 选项。 它还添加了仅由 SSH3 使用的新选项，例如 URLPath 或 UDPProxyJump。URLPath 允许您在 SSH3 命令中省略密钥 URL 路径。UDPProxyJump 允许您执行 SSH3 代理跳转，其含义与 -proxy-jump 命令行参数相同。 假设您在位于 ~/.ssh/config 的 OpenSSH 配置中有以下行：

IgnoreUnknown URLPath
Host my-server
  HostName 192.0.2.0
  User username
  IdentityFile ~/.ssh/id_rsa
  URLPath /my-secret-path

与 OpenSSH 类似，以下 ssh3 命令将使用位于 .ssh/id_rsa 的私钥通过公钥认证连接到运行在 192.0.2.0 的 UDP 端口 443 上的 SSH3 服务器：

  ssh3 my-server/my-secret-path

如果您不想使用基于配置的 SSH3 用法，您可以阅读以下部分，了解如何使用 ssh3 的 CLI 参数。

OpenID Connect 认证（仍处于实验阶段）

此功能允许您使用外部身份提供者进行连接，例如您公司的身份提供者或任何其他实现 OpenID Connect 标准的提供者，例如 Google Identity、Github 或 Microsoft Entra。认证流程如下图所示。

使用 Google 账户无需私钥的安全连接。

它与身份提供者的连接方式在名为 ~/.ssh3/oidc_config.json 的文件中配置。以下是用于 Google 账户的 config.json 文件示例。此配置文件是一个数组，可以包含多个身份提供者配置。

[
    {
        "issuer_url": "https://accounts.google.com",
        "client_id": "<your_client_id>",
        "client_secret": "<your_client_secret>"
    }
]

这在未来可能会改变，但目前要使此功能与您的 Google 账户一起使用，您需要在 Google Cloud 控制台中设置一个新的实验性应用程序，并将您的电子邮件添加为授权用户。这将为您提供 client_id 和 client_secret，然后您可以在 ~/.ssh3/oidc_config.json 中设置它们。在服务器端，您只需在 ~/.ssh3/authorized_identities 中添加以下行：

oidc <client_id> https://accounts.google.com <email>

我们目前正在考虑将来取消在 authorized_identities 文件中设置 client_id 的需要。

代理跳转

通常有些 SSH 主机只能通过网关访问。SSH3 允许您执行与 OpenSSH 类似的代理跳转。您可以使用 B 作为网关/代理从 A 连接到 C。B 和 C 都必须运行有效的 SSH3 服务器。这是通过在 B 上建立 UDP 端口转发来将 QUIC 数据包从 A 转发到 C 实现的。 因此，从 A 到 C 的连接是完全端到端的，B 无法解密或更改 A 和 C 之间的 SSH3 流量。