[erlang-patches] EEP Light: Option to override private key lookup when using Erlang ssh client

[Vipin Nair]

Hello Hans,

> You seem unaware of that both the client and the server get the keys
> from callbacks defined by the ssh_client_key_api and the
> ssh_server_key_api.  The option key_cb defines the module to use for
> ssh:connect or ssh:daemon.
> [.....]
>
> See
>   http://www.erlang.org/doc/man/ssh_client_key_api.html
>   http://www.erlang.org/doc/man/ssh_server_key_api.html

I am aware of this but it is very limited and will not fit my usecase. Let me
give you an example of my usecase and demonstrate the limitation of the above
API:

I have to connect to hosts `host1` and `host2` as user `foo`. I have the private
key corresponding to each user/host pair in a database. For simplicity sake,
let's assume I can call a named process (PRIV_KEY_SERVER) that will return the
private key data for a particular user/host pair. Something like:

  {ok, PrivKey} = gen_server:call(PRIV_KEY_SERVER, {get_priv_key, User, Host}).

Let's say we have a module(KeyCB below) that implements the ssh_client_key_api.
The definition could look like:

  KeyCB:user_key(Algorithm, ConnectOptions) ->
     {ok, PrivKey} = gen_server:call(PRIV_KEY_SERVER,
                                     {get_priv_key, User, Host}).


This function cannot be implemented because I have no way to get the value of
`Host`. The the ssh:connect/3,4 options that are passed as `ConnectOptions` to
user_key/2 do have that value.

Now:

 * I do not have the host name available and since host names need not be unique
   across machines, I have no way to get the private key corresponding to a user
   *and* a particular host from, say, a database.

 * ssh:connect/3,4 validates the connect options so we cannot just add an extra
   {host, "[HOSTNAME]"} to the connect options and get around the above
   limitation.

 * In my opinion, calling a database (or a named process like in the example
   above) from a module implementing ssh_client_key_api creates a high level of
   coupling that I would want to avoid when possible. Pragmatic way to do this
   would be:

     USER_INPUT -> FETCH_RELEVANT_DATA -> CREATE_SSH_CONN -> POST_CONNECT_STUFF

   This flows helps with error handling better. Let's say the named process dies
   for some reason, I do not wish to handle those kinds of error in my module
   implementing ssh_client_key_api. I want to keep external (Non SSH) IO
   elsewhere.

-- 
Regards,
Vipin