For note, if you don’t want it to generate a known_hosts file then if you pass in the hosts public keys in the proper option (silently_accept_hosts or something like that) then it will only use those, but it will not accept any others either, which can be quite good for security.

The first thing that strikes my eye is that the documentation for SftpEx.connect says

Other available options can be found at Erlang -- ssh

If you look at that documentation then you can pass the type client_options(). client_options() in turn includes the type common_option() and common_option() include key_cb_common_option()

That is the “key callback” options and seems to let you specify a module that follows the ssh_client_key_api. As near as I can tell that means you have to create a module that has a method called user_key that accepts an algorithm specification (like RSA, DSA, etc) and returns the private key that corresponds to that.

You could create such a module. In the implementation of user_key you could take the value of the key in the environment variable and put it into the format recognized by Erlang’s :public_key module. In a recent case I had the key in pem format and I had to combine :public_key.pem_decode and :public_key.pem_entry_decode to extract a key from pem data. user_key would return that key.

Then you pass the name of that module to the SftpEx.connect function as [key_cb: YourModule]

Now… having said all that, I just got that by reading the docs… I haven’t actually tried it.

Thanks for your help @easco - for the record we found an easier solution, by using the user_dir option to specify an alternative directory where the id_rsa private key is stored in the server where we connect from.

We also found that when connecting it tried to write the known_hosts file in that directory, so you can either give this directory write permissions, or pre-populate it with this file so it doesn’t need to be updated.

Hey Thibaut!

No, we finally chose the user_dir option instead, see my reply on Feb '19 above