Cloning from new host via ssh causes spurious error rather than prompting for confirmation and succeeding

[ctcjab]

Description

Using jupyterlab-git to clone a repo over ssh when the server is not yet in ~/.ssh/known_hosts causes the following "failed to clone" error:

Clicking "Show" produces the following somewhat spurious error:

The failure is due to jupyterlab-git not handling the case when the host key is not yet in ~/.ssh/known_hosts, so the error message should list that as a potential cause, in addition to the user not having access rights or the repo not existing.

Better yet, jupyterlab-git should handle this case and provide a graphical UI for the user to confirm, similar to how the command line git client exposes this via text UI:

$ git clone ssh://git@bitbucket.example.com:7999/foo/bar.git
Cloning into 'bar'...
The authenticity of host '[bitbucket.example.com]:7999 ([X.Y.Z.W]:7999)' can't be established.
RSA key fingerprint is SHA256:<fingerprint>.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[bitbucket.example.com]:7999' (RSA) to the list of known hosts.
remote: Enumerating objects: 18, done.
remote: Counting objects: 100% (18/18), done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 18 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (18/18), 560.80 KiB | 24.38 MiB/s, done.

This way the user doesn't have to switch away from jupyterlab-git to the terminal in order to clone the repo, which some less technical users may be unable to do by themselves.

Reproduce

1. Click "Clone a Repository"
2. Paste the URL of a git repo that is hosted via SSH and whose host's fingerprint does not appear in ~/.ssh/known_hosts
3. Click "Clone"

Expected behavior

Provide a user-friendly confirmation ("It looks like this is the first time you're cloning from this server via SSH, do you want to continue?" (perhaps with a "details" button the user can click to reveal more technical details, including the host key fingerprint). Once the user confirms, the confirmation is passed through to ssh so it can update ~/.ssh/known_hosts, and from that point forward the user can successfully use jupyterlab-git to clone from this host via ssh without needing to confirm again.

Context

• Python package version:

• Extension version: 0.50.1

• Git version: 2.34.1

• Operating System and its version: Ubuntu 22.04 LTS

Command Line Output

Paste the output from your command line running `jupyter lab` here, use `--debug` if possible. N/A

Web Browser Output

Paste the output from your browser web console here. N/A

[jesuino]

I am working on a possible fix for this issue. It is my understanding that the git clone hangs forever waiting for user input on the console, making it hard to verify host and re-try the command during the single git clone call.

To address this, I see two possible solutions:

1. Automated Host Verification:

   • Before initiating git clone, automatically check if the remote host is a known host.
   • If it's not recognized, present a prompt asking whether the user wants to add the host to their known_hosts file.
     • If the user confirms, proceed with adding the host and continue with the git clone.
     • If the user declines, cancel the git clone operation.

2. User-Friendly Fallback:

   • Preemptively check if the remote host is already a known host before running git clone.
   • If it's recognized, proceed with the command.
   • If not recognized, display a friendly message to the user, advising them to contact their system administrator to add the host to their known_hosts file.

Regarding the first approach, my concern is whether allowing every user to manually add entries to the known_hosts file might pose security risks. It would be prudent to ensure that such actions are handled securely and perhaps require administrative approval or specific permissions.

Kindle let me know your thoughts.

Thanks!

[ctcjab]

I am working on a possible fix for this issue.

Awesome, thank you!

It is my understanding that the git clone hangs forever waiting for user input on the console, making it hard to verify host and re-try the command during the single git clone call.

Note that the GIT_TERMINAL_PROMPT=0 env var can be set when calling git to make it immediately fail when input is needed rather than prompt for it interactively.

Also note that the GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no" env var can be set when calling git clone to configure ssh to bypass the known_hosts check.

However, the "correct" solution is probably to configure a git credential helper that would give the jupyterlab-git extension a chance to respond to "credentials needed" prompts by displaying a dialog in the UI and passing the user's input back through to git.

[jiridanek]

I think there are two aspects to this. First, there is the host key checking, and second there's the issue of providing user's credentials. These two are closely related for the resulting user experience, but still, for development they should be handled separately, in my view.

I was also enthused with the idea of credential helper, but, AI tells me

No, Git credential helpers will not directly help with the "Host key verification failed" error you are encountering.

Here's why:

Credential helpers manage authentication: They are designed to store and retrieve your username and password or SSH key passphrase so you don't have to enter them repeatedly when interacting with remote Git repositories.
Host key verification is about trust, not authentication: The "Host key verification failed" error occurs because your SSH client (used by jupyterlab-git under the hood) doesn't recognize the SSH server you're trying to connect to. It's a security measure to prevent man-in-the-middle attacks. The client wants you to confirm that the server's public key is legitimate before proceeding.

[jiridanek]

Users themselves have permissions to edit their known_hosts, no need to contact administrator for that.

That helpful AI suggested

Include instructions on how to manually add the host key (e.g., by trying to SSH from a terminal and accepting the key, or by using ssh-keyscan).

[ctcjab]

I was also enthused with the idea of credential helper, but, AI tells me...

I think the AI is being misleading here. IIUC when you configure a credential helper, git no longer directly talks to ssh to authenticate, but rather it always talks to the credential helper first to give it a chance to do its thing, and the credential helper can then intermediate any and all authentication flows.

So while git waits on the other end, it gives the credential helper a chance to do any extra checking it needs (including checking ~/.ssh/known_hosts), prompt the user for input (whether via a web-based GUI, native GUI, stdout/in, etc.), establish the authenticated session, cache the credentials, and then finally pass things back to git to take it from there.

[jiridanek]

establish the authenticated session

I guess this may be doable, but it seems far removed from what the credential helper is normally expected to do, which is, override username/password and exit:

While it is possible to override all attributes, well behaving helpers should refrain from doing so for any attribute other than username and password.

• https://git-scm.com/docs/gitcredentials
• https://git-scm.com/docs/git-credential#IOFMT

[jiridanek]

@jesuino Wow! https://github.com/hickford/git-credential-oauth

I think that for the auth part, what we need is to tell users to stop using ssh keys and just go with the (OAuth) flow! Users are in the web browser already, so OAuth login to a git forge is very natural thing to do.

It's so much more convenient and secure. No permanent ssh keys stored in the Jupyterlab project. Hopefully it can be arranged to work through Jupyterlab...

[jesuino]

Hello @ctcjab we sent a PR to discuss this, but we are still waiting for feedback. It would be great to have your input on the PR comments as well.

Thanks!