The ORA remote uses the datalad-core SSHManager. Apart from the complexity of OpenSSH deciding how to connect to a server, it adds support for the config setting datalad.ssh.identityfile. This is not only passed to ssh (overwriting any matching setting in its own host-based configuration), but is also used to determine an identifier for the socket name of a multiplex SSH connection (control master).
At present the test fixture recognized DATALAD_TESTS_RIA_SERVER_SSH_PATH for declaring a private key. The difference is, however, that datalad.ssh.identityfile applies to ANY connection. Declaring it for the entire runtime of the test battery will limit any SSH connection to this single key. This may be tolerable, but is certainly awkward.
I am thinking to complement the session-scope fixture ria_sshserver with a function-scope fixture that declares DATALAD_SSH_IDENTITYFILE based on the effective private key setup for the tests. This should limit the impact to individual tests only.
The ORA remote uses the datalad-core
SSHManager. Apart from the complexity of OpenSSH deciding how to connect to a server, it adds support for the config settingdatalad.ssh.identityfile. This is not only passed tossh(overwriting any matching setting in its own host-based configuration), but is also used to determine an identifier for the socket name of a multiplex SSH connection (control master).At present the test fixture recognized
DATALAD_TESTS_RIA_SERVER_SSH_PATHfor declaring a private key. The difference is, however, thatdatalad.ssh.identityfileapplies to ANY connection. Declaring it for the entire runtime of the test battery will limit any SSH connection to this single key. This may be tolerable, but is certainly awkward.I am thinking to complement the session-scope fixture
ria_sshserverwith a function-scope fixture that declaresDATALAD_SSH_IDENTITYFILEbased on the effective private key setup for the tests. This should limit the impact to individual tests only.