Adding ability to associate ssh keys with usernames

[costrouc]

@yuvipanda such a fan of the minimal(no) permissions that jupyterhub-ssh requires to launch terminals on behalf of users with their jupyterhub api key. We've added jupyterhub-ssh to qhub-onprem https://github.com/Quansight/qhub-onprem/blob/master/tasks/jupyterhub-ssh.yaml.

One issue we've seen with several clients is how they don't feel comfortable using password based auth and would prefer ssh keys. That said I know that the password the user supplies is used to launch the jupyter server on behalf of the user allowing jupyterhub-ssh to not have a sensitive admin api key. Do you have any design ideas on how to support this? We would be developing this feature. We would need to associate N ssh public keys with a given username and it would likely require the jupyterhub-ssh server to have an admin api key.

My idea on implementation. Often times I find that I need to associate metadata (often times not secrets) with a given user in this case public keys. I know that jupyterhub has auth-state but external api's do not have access to this data. If the hub had data about a user that could be queried over an api jupyterhub-ssh would have an easy way to gather associated ssh-keys for a user. This may be a feature that is waiting on rbac permissioning in jupyterhub to be completed https://github.com/jupyterhub/jupyterhub/tree/rbac.

[yuvipanda]

Great to see you, @costrouc.

In JupyterHub, admin services can actually access auth_state! So one way to do this is to get ssh public keys into auth_state on login, and have jupyterhub-ssh use that.

However, this sucks! jupyterhub-ssh currently has no privs required, which is great. I understand the need for this though.

The way to approach this is:

1. Implement a generic 'Authenticator' interface. These can take SSH keys or passwords, and they have to return a token for the user in JupyterHub.
2. Move the current user token based authenticator to this implementation
3. Implement using ssh keys from JupyterHub auth_state as second authenticator
4. Figure out how to keep generic non-encrypted state that's globaly accessible in JupyterHub. I'd love for 'profile' state that can contain many non-secret things, and is ideally editable by user. This might already be possible, though. Need to check.

Whatever we do here should match jupyterhub-sftp too. For ssh keys, that might mean some more work - probably involving AuthorizedKeysCommand. Should be doable though.

Happy to offer code review. Very excited to have you and others from quansight involved here :)

[manics]

jupyterhub/jupyterhub#3189 might be relevant?