这个特性将解决什么问题？

与准驾车型不符

#253 (comment)

我认为https从使用角度，将秘钥存在客户端是不安全的（这是我不能接受的）。从使用习惯，这是在倒退。

The access token can be used for Git clients, registries, pipelines, and robots. Fill in the password with the token to complete the authentication.

而且用户名都是：cnb（我咋听着，吹牛逼）

这么多场景，能不能分开。

设想的解决方案？如有

手自一体

1、git 存储 token 的方式很多，不仅仅是 store。可以选 跟随系统的凭据管理，cache ，store, .netrc, 乃至于 config 等

2、ssh 私钥 放置在 .ssh 和 git 的 sotre或者.netrc 是等价的。

3、凭据权限点你可以自己控制，你想多个凭据，那就分别配置不同权限点即可。

另外， .ssh 并不能解决你所提到的本地电脑被扫可能引起的安全问题。

你说的对。
我理解一个是主动，一个是被动。就好比，你把你的银行卡密码告诉我，我帮你充个会员。另外，就是我把我银行卡号给你，你把充会员的钱转给我。

1. cnb+token 怎么确保每个用户数据安全，数据会不会冲突。

2. token场景，自动化的那些场景，可以使用密码。本地客户端开发，可不可以使用SSH。

ssh 认证不打算支持，主要的考虑如下：

1. ssh 认证不支持匿名访问，这对公仓不友好，公仓明明能无凭证访问，ssh协议得带个私钥，多此一举
2. ssh 认证不能用于 docker registry / npm / openapi 统一管理，而 token 可以
3. https 已经足够普及，在传输安全上底层都为 SSL 协议，https基于CA 机制的的握手过程比 ssh 握手更安全，可更好的防中间人攻击
4. ssh 协议工作在TCP 4层，7层协议难以对 ssh 代理并加速

请出示你的驾驶证