Open drakkan opened 3 months ago
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Change https://go.dev/cl/602855 mentions this issue: design/68723-crypto-ssh-v2.md: new proposal
CC @golang/security
Here is the proposal for v2
https://github.com/golang/proposal/blob/master/design/68723-crypto-ssh-v2.md
updated API docs:
https://htmlpreview.github.io/?https://github.com/golang/proposal/blob/master/design/68723/ssh.html https://htmlpreview.github.io/?https://github.com/golang/proposal/blob/master/design/68723/agent/agent.html https://htmlpreview.github.io/?https://github.com/golang/proposal/blob/master/design/68723/knownhosts/knownhosts.html
Maybe we should open a discussion for this proposal, not sure.
We're seeking for rebasing our project onto upstream crypto/ssh
, and so far we found that the ability to disconnect from the client during authentication is missing.
Is it possible to add a new DisconnectError
and make serverAuthenticate
/clientAuthenticate
disconnect with the peer when a authentication callback returns it?
Proposal Details
In #65269 we discussed migrating the
x/crypto
packages and thus alsox/crypto/ssh
to the standard library and the proposal was accepted.The package
x/crypto/ssh
is one of the most used package inx/crypto
and so it is stable and works well. However, over the years we have accumulated several sub-optimal implementations to keep backward compatibility and we have realized that some interfaces are not implemented outside the packages itself and therefore can be removed.The ssh server implementation does not have a high-level API similar to net/http
ListenAndServe
and is therefore not consistent with user expectations.Furthermore, to have more consistency with the standard library APIs, we should rewrite the API that returns Go channels.
In v2 we can also remove deprecated API (e.g. DSA support).
In general, for client and server APIs we want to have both a high-level and a low-level API to provide an easy way to handle the most common use cases, but also to enable our users to handle more advanced use cases by using the low-level API.
I propose to first add a v2 to x/crypto and then move this version to the standard library. Design doc will follow.