Prompt for passphrase if private key is encrypted

[guludo]

Hi there.

By browsing the code and looking a some Github issues, it looks like that passing a passphrase as argument is required when the private key to be used is encrypted. While that makes a lot of sense, I think it would be nice if asyncssh provided a way to automatically prompt for the passphrase if the private key is encrypted. For example:

async with asyncssh.connect('localhost', client_keys=['my_ssh_key'], passphrase=prompt_passphrase) as conn:

Where prompt_passphrase is a callable that will interactively read the passphrase from the keyboard. Such a callable would be used only if my_ssh_key is encrypted.

[ronf]

This is an interesting idea! You wouldn't be able to invoke a regular callable directly if it was going to block waiting for user input, as that would prevent the asyncio event loop from making progress on other tasks. However, you could run something like that in an asyncio executor.

Here's a simple example of how you might do something like this yourself:

async def read_key(path, prompt_passphrase):
    try:
        return asyncssh.read_private_key(path)
    except asyncssh.KeyImportError:
        loop = asyncio.get_event_loop()
        passphrase = await loop.run_in_executor(None, prompt_passphrase)
        return asyncssh.read_private_key(path, passphrase)

In my test case, I used getpass to read the passphrase:

def prompt_passphrase():
    return getpass.getpass('Passphrase: ')

Then, to actually read the key, I used something like:

    k = await read_key('/tmp/k', prompt_passphrase)

If the key isn't encrypted, this reads and returns it immediately. If it is encrypted, though, the except block runs and requests the passphrase in an executor so that the event loop keeps running in the meantime. Once the passphrase is entered, it returns the decrypted key (or an exception if the passphrase was wrong).

With a tiny bit more effort, this could probably also be changed to support passing in an awaitable, which could be used without have to involve an executor while still allowing the event loop to keep running. I think something like the following would work:

async def read_key(path, passphrase):
    try:
        return asyncssh.read_private_key(path)
    except asyncssh.KeyImportError:
        if inspect.iscoroutine(passphrase):
            passphrase = await passphrase
        elif callable(passphrase):
            loop = asyncio.get_event_loop()
            passphrase = await loop.run_in_executor(None, passphrase)

        return asyncssh.read_private_key(path, passphrase)

This version accepts awaitables, callables, or a static value.

I see only one problem with integrating this into the existing AsyncSSH code. All of the functions that actually load the keys are non-async, expecting to always return immediately and with no guarantee that they are even being invoked from inside an asyncio event loop. So, at the point where the code knows if a passphrase is going to be required or not, there's no way to trigger this new behavior. It would have to be done up front in a async function (like in the example above).

[guludo]

Thanks for the explanation! I think I understand the problem you are pointing out.

I do not have much experience writing async code in python, but I wonder if we could check if we are running in an event loop and trigger the correct behavior based on that information. It looks like it is possible to check if we are inside an event loop:

import asyncio


def regular_function():
    try:
        asyncio.get_running_loop()
    except RuntimeError:
        print('Not in an event loop')
    else:
        print('In an event loop right now')


async def main():
    regular_function()


asyncio.run(main()) # Output: In an event loop right now
regular_function() # Output: Not in an event loop

[ronf]

Yes - it's possible to tell if a non-async function is called from within an event loop or not. However, a non-async function can't actually await anything. That's only possible from an async function, and the existing AsyncSSH API functions that take passphrases are almost all non-async functions right now. There are some exceptions, like the top-level connect() call, but all the functions that import or read private keys or key pairs are all non-async. A new API (using an async function) would be needed for them.

Given that a caller of AsyncSSH can do this sort of thing themselves in just a few lines of code, I'm not sure it's worth the disruption it would cause in the existing library code to try and add it there. I do like the concept, but if the caller knows they need this, it could be as simple as replacing:

    k = asyncssh.read_private_key(path, passphrase)

with:

    k = asyncssh.read_private_key(path, await prompt_passphrase())

...if prompt_passphrase was an awaitable. If it is a plain callable, it's one extra line, but still quite easy:

    loop = asyncio.get_event_loop()
    k = asyncssh.read_private_key(path, await loop.run_in_executor(None, prompt_passphrase))

In Python 3.9 and later, this gets even simpler for callables:

    k = asyncssh.read_private_key(path, await asyncio.to_thread(prompt_passphrase))

[ronf]

Closing due to inactivity. Feel free to re-open this or create a new issue if you're unable to get the above suggestions to work.

[goblin]

The approach you've suggested relies on knowing the path to the key, and knowing that a key file will be used at all. AsyncSSH already determines this, but doesn't seem to export functions that could ease this for the user (i.e. something like get_keyfilename_for_connecting_to(host)). Users of the library thus have no easy way of determining that they need to prompt for a passphrase (or a password, for that matter). They would need to parse the config files again.

I think it would be pretty nice if SSHClientConnectionOptions supported a new option to provide an awaitable to prompt the user for passphrase or password (passing the name of the keyfile being tried, or e.g. None if a password is needed).

[ronf]

Interesting idea. I'll take a closer look at this over the weekend.

My thinking is to simply allow the existing password and passphrase arguments to optionally be an awaitable. When this is the case and the value is needed, the awaitable would be executed and return the value. In the case of passphrases, the awaitable could be called with the key filename as an argument. This would mean probably not supporting the awaitable for import_private_key, but it's probably not all that necessary there since the caller is passing in specific key data and should already know the passphrase to use for it.

For passwords, there's already support for a callback by subclassing SSHClient and implementing password_auth_requested on that class. However, supporting an awaitable here would be less code for the caller, and I don't think it will be all that difficult to implement.

[goblin]

Yes, the solution you're proposing is even better. I also don't think import_private_key needs to support an awaitable.

Many thanks!

[ronf]

Ok - part 1 of this change is now in the "develop" branch as commit f4df7f4. It adds support for the password argument in SSHClientConnectionOptions to be a callable, coroutine function, or an awaitable which return either a string or None.

Note that you if you are trying to prompt for a password interactively through stdin/stdout, you need to be careful not to do blocking I/O there, since that will block the event loop from running.

If you choose to do async I/O on stdin/stdout, that may cause other problems if you later try to use blocking functions like print() or do logging to there.

Next up is a similar change for setting the passphrase to use when loading private keys from files.

[goblin]

@ronf please also check out #641 as it might be related.

[ronf]

As it turns out, supporting an awaitable when loading key pairs is a bit tricky, as the load function itself is not currently an async function. All of the functions which determine the config (including the key-loading functions) are synchronous right now. It would be easy to add support for a callable here, but it would be much trickier to add support for an awaitable. So, I think as an initial attempt I'll add support for only a callable in this case.

[ronf]

Ok - I've got something working here, but I'm not sure it will solve your use case, if you really need to make a blocking call after finding out which key file is being loaded. You'd basically have to do the key loading prior to starting the event loop, or be ok with the loop blocking all tasks until the passphrase was provided. Once the key is decrypted, you could then start up an event loop with the already-loaded set of keys.

[ronf]

Looking at the code more closely, the main AsyncSSH connect/listen functions already do the config evaluation in a separate thread (using an executor), so it turns out that running the synchronous callable won't block the asyncio event loop after all. It could if you created your own SSHClientConnectionOptions object, but if you wanted to do that you'd just need to make sure that you created that options object from within an executor as well, and the callable you provide will be run from within that.

A first cut of this code is now checked in as commit 56e533b if you'd like to give it a try.

[goblin]

I was hoping to prompt for the passphrase using Textual's ModalScreen dialog. Textual also uses asyncio for all its magic.

Do I understand correctly, you're saying that:

1. AsyncSSH's .connect() will run in a separate OS thread and will call my callable there, and
2. my main asyncio loop will continue running while that thread waits for the callable to finish?

If that's the case, then I believe I could use the thread-safe queue.Queue to communicate the passphrase from my main thread (running the asyncio loop) to the blocked .connect() thread, am I right?