为什么公司不允许 ssh 链接 gitlab

还是菜呗

感觉用 ssh 协议访问 gitlab 应该没啥问题吧

的确不理解。有没有懂行的来讲一讲。

我觉得应该 ssh ，而且账号必须开两步验证

1. SSH 不能加 SSL ，如果没有通过其它渠道公布 host key 可以被中间人攻击，即使是在内网
2. 可能是像 vsftpd 给 chroot 标记不安全的那种原因

反正我配的 GitLab 也不允许 SSH 连接，攻击面能少一个是一个

确实无法理解，我基本都用 ssh

我觉得是菜...

是直接屏蔽了 22 端口的话，可以试试 443 端口的 ssh

去年公司做等保正要遇到过, 等保会扫描公司服务器, 扫到 gitlab 服务的 22 端口开了, 责令整改, 所以只能关掉了.

@edis0n0 soga
@yfugibr 试了```ssh -T -p 443 [email protected].**.com```但是返回```ssh: Could not resolve hostname ssh.git.**.com```是 443 也不允许的意思吗？

@edis0n0 ssh 不行那 gpg 呢？

我们也不能用 SSH,据说是为了限制 IP 访问.
但 SSH 应该也有办法解决吧? (不了解)

@breadykidliu 看着是没解析到域名？你们正常域名就是 ssh.* 的吗

@breadykidliu 另外如果是搭建的时候就没开 ssh 那就没办法了

我们公司一开始是可以 ssh 的，后来关掉了 ssh 只让用 http ，我也没搞懂

@yfugibr 正常是 git.**.com ，```ssh -T -p 443 git@git.**.com```请求返回 ```ssh_exchange_identification: Connection closed by remote host```那应该是是不行了- -

当你的电脑被入侵了之后就不一样了

中厂是什么概念？我经过的几个厂都是 ssh

@skull 用了 mac 之后没遇到什么安全问题，杀毒软件也没装

@icyalala 10 年以上的上市公司

就是 IT 技术不到位而已，不用研究太深。我们从 5 人团队起步，没听说过不能用 ssh 这类话题，人多起来之后为了安全加了一道 engineering vpn ，git 机器放内网，非常轻量。

ssh 不是比密码更安全吗

SSH ,需要放开服务器的 ssh 协议给所有人，对于安全团队来说，绝对是不被允许的，在放开 git 的同时，也放开了远程登录的入口，风险太大了，理解一下安全人员吧，而且又不是不能用，为什么要公司为了将就你的习惯增加公司风险

宝马总公司 IT 总部这里依然是建议不使用 ssh.

但的确开放出来了，并且对一个 ip 的 ssh session 做了限制。

是宝马内部的 gitlab.

一个是宝马内部网络很复杂，有很多专线网络互通采用 nat.你一个人把一整个分公司那可怜的 5 个 ssh session 给占满了，别人就用不了

另外一个问题是安全考量

你们觉得是因为菜才禁用，那是以你们程序员的视角来看的。。。运维人员反而觉得你们更菜，连基本的运维安全角度都没有考虑过，只觉得从自己单方面使用便利不便利的角度来看待事物。。。

@jwangkun #22 你在说什么? 感觉你和其他人不在一个频道上

因为主管网络策略的部门不允许 ssh 连接。所以只能通过 https 去访问了，其实和菜没关系。我们测试环境和生产是同样的安全等级，你敢信- -。

@mrzx 你说的对，我就是安全从业人员，也是开发人员

猜测是安全策略好做吧？所有 SSH 外部流量均拒绝？

@jwangkun git 的 ssh 根本不是服务器 login 的 ssh, 各自独立的. 端口一般都设成不一样的.
https 的 ssl 并不会比 ssh 的 ssl 安全, 都是一样的算法.
菜就是菜

#9 说的是一种可能。我司碰到过，等保扫描规则认为开放 22 就是不安全，从技术上解释也没有意义，规则就这么定的，这条就是不合格。

当然，可以开通非标准端口 ssh ，但也有额外沟通成本，可能就关掉省事吧。

@f6x 现在最辣鸡的安全设备,也不是按端口去封..按协议封是常态,都是按流量特征去识别的,而且大部分检测只要测到 22 都会被通告,对运维人员来讲
开,大概率被安全通报
针对客户端 ip 开,网络安全流程麻烦
还不如关了

作为某大厂、安全策略实施者，我来终结此贴：因为 ssh 审计成本大，需要专门配置解密器，才能限制上传和下载两个权限。而 https 目前解密技术成熟、高效，可以快速识别。就是这么简单。别的地方不说、我这里最近半年就查到 10 起代码上传违规、不管起来、还不得上天？

因为 22 口是重点检测，大部分时候被一刀切了

我记得可以在 git 的配置文件里指定用户名和密码，配置好之后不用每次输入了

@weizhen199 可以改端口的

@SteveRogers 确实.

美企大厂也只能 http. 并且公司定期 google 外网上包含公司标签的内容. 每年审计出好几个好多人把公司代码传到 github 的例子.

感觉相反呀 只允许 ssh

因为 https 帐号密码更不安全，ssh 走 kinit 认证

sshd 又不是不能开两个,分别两个配置文件，然后那个用来做 git 的做好权限隔离

GitHub 建议 HTTPS ，没啥特别的原因，只是 HTTPS 相对来说更容易部署和防火墙不用做额外策略。

github 配 access token 就挺麻烦的

应该是不让开放 22 端口

我搭的 gitlab 也不开 ssh ，http 也不开，为了安全。 提交都是用移动硬盘复制给指定的人然后合并的。

@hefish #42 我们都是用纸笔写代码的，为了安全，雇个大学生每天把纸上的代码手敲进去，把执行结果抄回来

@SteveRogers 很好奇是怎样的代码违规？能举个例子吗

可能设了一些安全机制

劳动异化就变样了。专职安全岗位的人对安全的考虑，跟有安全意识、安全理念和安全技能的其他岗位（比如开发）是不太一样的。他们不但要从技术上考虑系统的“正常”安全加固，还要跟各种没有安全意识和能力的其他人员搏斗，要去补木桶的最短板，因此经常会采取一些在非安全岗位但有安全能力的技术人员眼中很没必要的沙雕措施。更何况，这是他们的岗位，所以除了对技术之外，也要（甚至更多地）考虑成本 /收益核算，考虑性价比，也包括考虑怎样给自己增加 KPI （哪怕会给业务运行或者技术开发带来一定的麻烦）。

安全岗位也不过是一口饭而已。照本宣科的大有人在。

上面信誓旦旦的几位谁能给我解释解释，为什么用 http 就能防止把公司代码传到外网？

@JohnBull 公司所有终端设备上装 root ca ，然后安全设备做中间人攻击，分析 https 内容是否有公司代码上传到 github 之类。ssh 协议直接防火墙 ban 掉。

@swulling 这种外网安全需求应该从外网访问的策略上限制啊，为什么让大家用 ssh 上传到公司自己的服务器也不行呢，这就叫懒政

@swulling 那这样 Gitlab 在内网也不影响防火墙 Drop 公网的 SSH 的。

因为，大部分人都不知道 git-shell 这东西。

@JohnBull
@azuis 至于内网，多数是多一事不如少一事。安全扫描 ssh 端口，但是又分不清楚哪个是 git 的。

加白名单需要逐级审批，不如一禁了之。

在阿里集团 gitlab ssh/http 都支持，没有限制，自己选择

@f6x 笑死了，你自己去记端口吧，干脆也别用域名了直接用 IP 吧，你行你上就是了

@jwangkun Git 服务的 SSH 协议很危险吗？这货不是不支持远程登录进终端么，为啥说风险大？求科普

@IvanLi127 个人觉得安全性两种方式都一样，但是安全这个东西是个硬指标。最小化权限原则，就和企业服务器不允许对外开放 ssh 一样，能不开就不开。既然 gitlab 已经提供了 http 的方式就没必要再多开一个了。任何做法没有对与错，也无需大厂比较，自己爱咋用咋用。 觉得内网就安全的我只能说太年轻了，尤其是没做隔离的情况。 说人家菜的我只能说傻逼

无他，菜。
SSH 也可以配合 yubikey 之流做认证，完全不需要担心 ssh key 泄漏后的安全问题

如果是安全原因，那么 github.com 是不是早就应该被黑客干烂了？

gitlab 可以设置其他端口 ssh 访问啊，都不知道吗？不让用 22 可以换别的
而且 git 账户 ssh 是低权，ssh 远程登录也是不开放的

是不是怕用户使用 ssh 登录 gitlab 服务器？

我们公司就跟你们不一样 我们禁止密码连接 只允许 ssh 连接

在我看来，90%的代码都是没用的，不要把代码看得那么值钱的样子，值钱的不是代码而是产品

Gitlab 的 ssh 本身的安全性还是挺有保障的，没有 shell ，我分析过，写了一篇文章：

当你 git push 时，Gitlab 上发生了什么？
https://nanmu.me/zh-cn/posts/2022/what-happens-on-gitlab-when-you-do-git-push/

@Nitroethane
1.深 x 服对上传流量识别和终端抓取的访问记录匹配
2.定期扫描 github 里面含有内部关键词的仓库（国内安全大厂有这个服务直接买就行）

@nanmu42 企业安全不会考虑技术上的绝对安全，只考虑相对、关键好管控，能轻易抓到违规才是安全人员的职责

@JohnBull 内网确实要允许，是安全人员偷懒了

HTTPS 是 HTTP 外套 TLS/SSL ，协商的时候大体上是：客户端接收服务器公钥和签名，根据客户端上的 CA 证书来验证服务器可信(认证)，然后使用服务器公钥发送客户端的公钥和数据，服务器用服务器私钥解密再用客户端公钥加密数据返回，客户端用客户端私钥解密。
SSH 是 Secure Shell ，协商的时候大体上是：客户端接收服务器公钥，然后看本地是否记录过，未记录再提示用户验证是否可信(认证)，然后客户端生成对称秘钥，用 Diffie - Hellman 算法在不直接传输秘钥的情况下、以服务器公钥加密相关参数的形式然后服务器自己把这个对称秘钥算出来，然后双方通过这个临时对称秘钥加密通信。
总体来说只要验证身份阶段把好关、秘钥和算法足够强、私钥不泄露，两种方式都是十分安全的。
关于 SSH 端口，其实可以分开运维用端口和 Git 端口，一种简单方式是把 Git 服务部署在 Docker 等隔离环境中，内部配置 SSHD 仅允许 git 用户访问 git-shell ，需要运维则登录到宿主机再使用 Docker 的 exec 指令打开 shell 操作。SSH 不使用 22 端口，用户也可以在客户端配置 remote 的时候指定其他端口。
有的企业可能规定不允许记住登录状态，比如配置公钥自动登录这种就不符合要求，但其实可以打开两步验证，实际上现在等保会要求两种及以上验证方式同时使用。
个人认为题主的情况要么是因为其他原因，要么是运维人员水平有限，要么是安全负责人员懒政。

@swulling 对、两道防线
1.所有机器加域了、证书早就内置了
2.大厂还部署了专门的解密器、所有流量复制了一份给解密器，异步解密识别

@James369 所以阿里、腾讯相对宽松一些、互联网的安全主要防攻击、对内部人员的行为不会太严，他们主要聚焦核心算法、或极少数核心代码、对大部分人设置红线。

@darklinden 流量识别、你换啥端口都一样、我们后台看到的都是 ssh 协议

前面有说了，SSH 没有 PKI 支持，需要额外的 host key 信任机制。大家 ssh 的时候有几个会注意 finger print 的？

只用 https 对基础设施运维扩展长期是有好处的
对于流量监控审计也更方便
当然，不上规模的企业也不用考虑这些

盲猜是网关屏蔽了所有生产环境的 22 端口，gitlab 是只是顺带屏蔽了，而不是故意不开 gitlab 的 ssh

@SteveRogers 我前面回复的是禁用 22 端口的问题。
为了拆所有的包看于是自定义证书然后只允许 https ？有路由不知道是 git 服务器的 ssh 连接，有记录不知道是 git 服务器的提交，所有代码提交都要安全部门过一遍，安全部门可以拿到所有的代码和更改？有种东厂西厂的感觉了