Allow passing state around SSH callbacks #10528
Description
Is your feature request related to a problem? Please describe.
I am attempting to implement a Git server in Elixir (using Erlang/OTP's ssh application), but I'm struggling to find a way to implement my desired functionality without reimplementing a major part of the ssh application's code.
Describe the solution you'd like
I feel that it should be possible to hook into certain parts of the SSH flow, such as authentication, and pass state around. This is already partially possible with ssh_server_key_api:is_auth_key, but it does not allow associating connection-local state with this authentication request, giving no way to identify users beyond SSH usernames.
Without this, I cannot have a unified ssh://[email protected]/user/repo clone URL instead of a per-user URL, like what is common in many Git hosting servers.
I am unsure of how this should be architectured, but I feel that it should be possible to do. I think it may be worthwhile to look at something like the Rust russh crate's Handler API for inspiration, as I was using that previously and feel that this functionality could be implemented similarly by passing "handler" state around per connection and defining certain callbacks. Such an API could also unify some of the stratified callbacks of ssh application daemons into a unified behaviour, which may be better for other users of the ssh application too. However, I am open to other solutions though, of course!
Describe alternatives you've considered
I have considered using unique usernames. However, I find this a suboptimal solution that would degrade the user experience of those using my Git server.
I think at the moment, as I have started writing this application in Rust and wanted to try using Elixir, I will simply use Rust's russh crate with a port. However, having to shell out to external languages/programs for behaviour that could be implemented within an already-existing OTP component is suboptimal and introduces a potentially large maintenance overhead and could introduce fault tolerance and performance issues compared to an OTP-native solution.