能否增加ssh方式拉取仓库#253
ssh 认证不打算支持了，主要的考虑如下：
- ssh 认证不支持匿名访问，这对公仓不友好，公仓明明能无凭证访问，ssh协议得带个私钥，太返祖
- ssh 认证不能很方便的用于 docker registry / npm / openapi 统一管理，而token可以
- https 已经足够普及，在传输安全上足以匹美 ssh
- ssh 协议工作在TCP 4层，7层协议难以对 ssh 代理并加速
ssh 认证不打算支持了，主要的考虑如下：
- ssh 认证不支持匿名访问，这对公仓不友好
- ssh 认证不能很方便的与docker registry / npm / openapi 统一管理，而token可以
- https 已经足够普及，在传输安全上足以匹美 ssh
- 难以对 ssh 协议加速或代理
事实上，很多团队 是使用 ssh 来操作仓库的，
很希望 这个项目 在未来能支持 SSH~
用户可以不用，但是不能没有。
上面的 1，2，3，4 的理由很牵强，站不住脚的。@youkun
同意，建议能加上SSH~
其实， 和 拉取 没关系，
而是 希望能支持 关联的所有操作。
最重要的是 开发团队的代码提交。。push ！
还有一点很重要，比如我们内部经常用一些构建工具，支持ssh就很方便，总不能在代码里写上明文https://user:pass@cnb.cool/xxx/xxx吧😂，用环境变量也不如ssh公钥方便，好管理。
1.cnb+token 确实很方便，但是从安全角度，将密码存在客户端，（从服务器角度看）是不安全的，经常有人恶意取获取.git-credentials，我都不相信自己电脑是安全的。分别设置也比较麻烦。另外，这token看着有些短。 2.从开发，构建的时效性，使用习惯，以及考虑本地电脑能效利用率，workspace一般写个Readme，而且也没有Idea方便。 3.coding中的项目，在这里使用group替代，刚开始有些不习惯，感觉还好。
事实上，很多团队 是使用 ssh 来操作仓库的，
很希望 这个项目 在未来能支持 SSH~
用户可以不用，但是不能没有。
上面的 1，2，3，4 的理由很牵强，站不住脚的。@youkun
@zc035(张聪) +1
ssh 认证不打算支持了，主要的考虑如下：
- ssh 认证不支持匿名访问，这对公仓不友好，公仓明明能无凭证访问，ssh协议得带个私钥，太返祖
- ssh 认证不能很方便的用于 docker registry / npm / openapi 统一管理，而token可以
- https 已经足够普及，在传输安全上足以匹美 ssh
- ssh 协议工作在TCP 4层，7层协议难以对 ssh 代理并加速
@youkun(哪都通在逃临时工) 这四条除了第二条都不算理由吧，说白了还是为了简化统一认证
ssh 认证不打算支持了，主要的考虑如下：
- ssh 认证不支持匿名访问，这对公仓不友好，公仓明明能无凭证访问，ssh协议得带个私钥，太返祖
- ssh 认证不能很方便的用于 docker registry / npm / openapi 统一管理，而token可以
- https 已经足够普及，在传输安全上足以匹美 ssh
- ssh 协议工作在TCP 4层，7层协议难以对 ssh 代理并加速
@youkun(哪都通在逃临时工) 问的是“增加ssh”，你这回答的完全是“替换成ssh”，答非所问。本来是十进制游戏，非要玩成二进制游戏。
@youkun(哪都通在逃临时工) 问的是“增加ssh”，你这回答的完全是“替换成ssh”，答非所问。本来是十进制游戏，非要玩成二进制游戏。
@cnb.as5ad41EAEA(姚瑞峥) 还有个增加其他登录方式也是，死活不肯加，给的理由也是这种，把"增加"偷换概念成"替换"
这个特性将解决什么问题？
团队内部私有仓库可以直接用ssh免去用户名和密码
设想的解决方案？如有
No response
您考虑过哪些替代方案？如有
No response