系统与基础设施medium.com
为什么我们不把 SSH 用于一切？
Why aren’t we using SSH for everything?
2015 — 2017，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者 shazow（SSH 库 Paramiko 的维护者之一）撰文探讨 SSH 协议的设计与能力，提出一个引人思考的问题：既然 SSH 内建认证、加密和多路复用，为什么我们不把它当作通用协议用于一切场景？文章介绍了 SSH 的工作原理及其被低估的用途。
为什么经久不衰：它把一个大家天天用却很少深究的协议讲透，并引出“通用协议该选谁”的经典争论，多年后读仍能启发对 TLS/HTTP 与 SSH 取舍的理解。
HN 评论精选
SSH 为交互式响应优化，不适合高延迟下的大流量传输
首先，SSH 在高延迟链路上传输大文件的性能非常糟糕。SSH 的 TCP 窗口很小，因为它为快速响应而非批量传输优化（毕竟它最初是远程 shell 协议，scp 和 sftp 是后来才加的）。而且目前即使想改缓冲区大小也改不了。更多信息见 HPN-SSH 的资料。
otterley查看英文原文
For one thing, SSH performance for large transfers is abysmal over high-latency links. SSH uses a small TCP window size because it was optimized for quick response, not bulk transfers. (After all, it was designed to be a remote shell protocol, not a generic file transfer protocol; scp and sftp were added after the fact.) And unfortunately you can't currently specify a different buffer size even if you wanted to. More information can be found here: http://www.psc.edu/index.php/hpn-ssh
SSH 公钥体系天然优雅地解决了单点登录和密码管理难题
另外值得一提：SSH 通过 agent 转发内建支持单点登录。只要我的公钥在某个地方可用，我就能在任何地方被任何系统认证。密码本质上是共享密钥，发给服务器就意味着信任它不会丢失；而 SSH 公钥不需要如此小心地管理。
kgilpin查看英文原文
Something else worth mentioning; SSH has built-in support for single-sign-on, via SSH agent forwarding. As long as my public key is available anywhere (and that's exactly what it's designed for), then I can be authenticated by any system, anywhere. Thus, a problem which is so vexing in so many other scenarios, is very cleanly addressed by SSH. Fundamentally, a password is a shared secret. So you send your password to a server, you are trusting that server not to lose or misplace it. In contrast, an SSH public key doesn't require nearly such careful management.
TCP 套 TCP 的隧道会相互干扰导致连接劣化，是 SSH 通用化的硬伤
TCP over TCP 隧道是不是有问题（自动节流机制本意是防止包碎片）？我每次用 ssh 隧道跑打印或 HTTP，连接跑一段时间就劣化。虽然也许能调参数，但我觉得这是“一切走 SSH”的主要障碍，因为 SSH 底层用的是 TCP。
ivan_ah查看英文原文
Isn't there a problem when you tunnel TCP over TCP with increasing window sizes (auto throttling mechanism meant to prevent packet fragmentation)? Every time I've tried to keep a long-running ssh tunnel for printing / http, the connection degrades after a while. I'm sure there are some flags that can be set, but I thought this was the major show stopper for the "everything over shh" (since ssh uses TCP protocol)
安全专家认为 SSH 协议质量不如 TLS/HTTP 栈，不应作为通用协议
因为它并不是一个很好的协议。采用 SSH 而非 HTTP/2 和 TLS 1.3，等于同时继承了 TLS 的所有坏处（尤其是 1990 年代的密码学遗产）和 SSH 的所有坏处（性能差、极度复杂），却没有任何好处。SSH 默认允许任意 TCP 端口转发，配置失误很容易被攻破；而 HTTPS 栈需要主动开启转发。SSH 更擅长交互式终端会话，HTTP 在其他所有方面都做得更好。
tptacek查看英文原文
Because it's not a very good protocol. Adopting it, instead of HTTP/2 and TLS 1.3, basically gets you everything that is bad about TLS (most notably, a legacy of 1990s cryptography) and everything that is bad about SSH (poor performance, extreme complexity), and leave you with no upsides. For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to prevent accidental forwarding. The SSH stack, on the other hand, requires you to opt out of arbitrary TCP/IP port forwarding. Screwing that up will, more often than not, get you owned up Phineas Phisher-style. The things this post appreciates about SSH are equally available in the HTTPS stack (even more so in the HTTP/2 stack). Unlike SSH, with its janky Connection Protocol, HTTP has for the last 10 years been designed as an arbitrary application protocol. SSH does a better job providing interactive terminal sessions. HTTP does a better job at everything else.
从大规模运维角度看，HTTPS 比 SSH 更易扩展和管理
问问 GitHub 和 Heroku 这类服务商更偏好哪种 git 协议：SSH 还是 HTTPS。答案是 HTTPS。管理数百万客户公钥的 SSH 服务器很痛苦，SSH 实现有很多怪癖和副作用；shell 命令解析和转义很吓人；还有 Windows 的问题。HTTPS 加基本认证头更容易扩展，唯一的坑是 HTTP git 花了些时间才做到和 SSH 一样高效的传输。
nzoschke查看英文原文
Ask a provider like GitHub and Heroku which git protocol they prefer: SSH or HTTPS. The answer is HTTPS. Managing an SSH server with millions of customer pubkeys is a pain. Python/twisted and Go have decent SSH implementations but there are quirks and side effects a plenty. Shells are scary. You have to be very careful about how you execute the program on the remote side of the pipe. Shell command parsing and escaping is gnarly. Windows... HTTPS with basic auth headers is much easier to scale. The one gotcha is that it took a while for HTTP git to get "smart" and offer as efficient transport as SSH with access to a .git dir.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选