本文翻译自极狐GitLab的官方博客，详细介绍了gitlab-sshd计划完成的背景以及该组件和OpenSSH相比较之下所具有的优势，供咱们参阅。正文内容如下
为什么要转移到咱们自己的SSHD，这背面的故事也非常风趣。GitLab供给了很多经过SSH衔接履行的特性，最盛行的一个便是Git-over-SSH，让咱们能够经过SSH和一个Git服务端进行通讯。由于一些历史原因，咱们经过OpenSSH和一个独自的组件，一个叫做GitLab Shell的二进制文件的组合来完成这些特性。GitLab Shell处理每个OpenSSH服务端树立的衔接，以在 SSH客户端和 Git 服务端之间来回传递数据。这个计划是久阅历练且依靠一个新人的组件，例如OpenSSH。下面是咱们为什么决议完成咱们自己的SSHD。
社区奉献
每个人都能够给GitLab奉献！而gitlab-sshd便是一个来自lorenz的社区奉献，作为咱们已有安装里的一个轻量级替代计划。一个只需求很少外部依靠的独立二进制文件关于容器化布置来说非常有优势，一个GitLab支撑的替代计划也能够翻开新的机会：
- PROXY协议支撑让经过SSH的群组IP地址约束成为或许：群组IP地址约束在
GitLab Shell + OpenSSH的计划里无法完成，由于OpenSSH不支撑PROXY协议。因而，GitLab Shell无法看到实在用户的IP地址。咱们不得不运用一个打补丁的OpenSSH版本或许完成咱们自己的计划来支撑PROXY协议。运用咱们自己的计划，咱们能够供给PROXY协议，接纳到用户的实在IP地址，并供给群组IP地址约束功能。 -
Kubernetes里滑润封闭、存活性和就绪性勘探等特性的兼容：运用OpenSSH，咱们无法控制已树立的衔接，当Kubernetes Pods轮替时，一切进行中的衔接都会被立即丢掉，会导致长期运转的git clone操作被打断。有了专用的服务端今后，衔接现在是可管理的且能够被滑润封闭：服务端监听中止信号，当接纳到信号时，停止接纳新的衔接并在完全封闭之前等待一个滑润周期。这个滑润周期让正在进行的衔接能够正常结束。 -
Prometheus目标和剖析成为或许：在咱们之前的布置方法里，GitLab Shell只是一个二进制文件，用来创立和SSH衔接存活时间一样长的进程。这种方法无法供给一种直接的方法来运转目标服务器。而运用专用的服务器，咱们现在能够收集目标并完成概况记载，用于监控和调试。 - 在一些场景下，功能有了显着的提升，资源运用率有了显着的下降：轻量级的协程相关于每个SSH衔接都创立一个独立的进程来说资源耗费更低。在根底场景里，创立一个独立的进程表现的更好。可是，运用
gitlab-sshd能够引进一个Go剖析器来处理功能问题，从操作方面来说，是一个显着的提升。 - 仅运用一个约束的SSH完成特性集来下降进犯问题：运用之前的方法，咱们允许树立一个到
OpenSSH服务端的衔接，可是将它约束到一个特定的特性集。运用gitlab-sshd，对一个咱们还未支撑的OpenSSH特性的任意未预料的调用再也不或许了，戏剧性的下降了进犯问题。 - 简单的架构更容易了解。
之前的架构
当前的架构
危险和应战，
可是，修正一个广泛运用，且负责安全的组件，会带来巨大的危险。咱们一起阅历了应战和危险：
- 安全方面：一个
SSH服务端是一个要害组件，它在用户和服务端之间树立一个安全衔接，并允许他们之间暗里通讯。任何错误都或许翻开安全漏洞，允许从认证绕过到长途代码履行等各种操作。要减轻危险，咱们履行多轮安全查看 – 开发之前（查看运用的组件）、开发中、以及在作业版本代码布置到预发布环境之后。 - 操作方面：这个组件是广泛运用的，任何错误会影响很多的用户。要减轻这个危险，咱们渐进式地添加改变流量的比例，从1%、到5%递增。并且在遇到问题的时分立刻回滚。在8次尝试之后，咱们让这个服务端成功接纳处理了100%的流量。
咱们遇到的问题
运用范围如此广泛的组件会有大范围的问题，咱们遇到并处理了下面的问题：
- 和其他进行中的特性不兼容：咱们第一次
gitlab-sshd布置耗费了很多的内存，它和其他正在开发中的特性交互产生了负面影响。咱们在引进一个通用组件时必须时间记住和其他组件的交互。 - 在
golang.org/x/crypto库里有限的特性集：这个库用来树立SSH衔接，并且有限支撑在OpenSSH里可用的算法和特性。咱们创立了咱们自己的分支来供给缺失的特性。-
OpenSSH客户端在8.2版本里由于一些安全原因废弃了主机证书里基于SHA-1的签名。可是经过server-sig-algs扩展供给了向后兼容。可是golang.org/x/crypto不支撑它。咱们开端支撑这个扩展; - 一些
MACs和密钥交换算法不支撑：hmac-sha2-512和hmac-sha2-256是最显眼的，咱们也开端支撑这些算法; - 有问题的SSH客户端，例如在
Ubuntu 18.04里附带的gpg-agent v2.2.4和OpenSSH v7.6，或许会发送ssh-rsa-512作为公钥算法，可是实际包括一个rsa-sha签名。咱们不得不放松RSA签名查看来处理这个问题。 - 从头完成
OpenSSH里可用的选项：了解的OpenSSH选项像LoginGraceTime和ClientAliveInternal不可用，所以咱们完成了多个替代项来保留咱们需求的特性。
-
学习到的东西
不幸的是，在生产环境上问题变得可见.感谢压力测验以及各种或许的OpenSSH配置,即便在咱们的预发布环境上已经捕获到了一些bug，猜测一切类型的问题仍是不或许。可是，下面这些动作协助咱们处理了这些问题：
- 增量布置：这个布置计划被证明及其有效，让咱们能够在迭代的一起不会中止大部分用户的服务。
- 寻求多视角：咱们寻求了很多团队的意见，例如安全、架构、质量和扩展团队。协助咱们从多个方面评价这个项目，下降危险并阻挠很多问题的产生。
