Too bad, probably. I don't know any way to tell ssh always to fail non-interactively here.

If it shows up in verbose mode, that'll probably have to be good enough

You provided no way to reproduce this.

After writing the below I noticed -o BatchMode=yes which should disable any interactive prompts.

https://man.archlinux.org/man/ssh_config.5.en#BatchMode

I think -o StrictHostKeyChecking=yes would make this specific case fail non-interactively.

-o PasswordAuthentication=no I think would cover #9626

https://man.archlinux.org/man/ssh_config.5.en#StrictHostKeyChecking
https://man.archlinux.org/man/ssh_config.5.en#PasswordAuthentication

to reproduce the issue comment out any entries for github.com in ~/.ssh/known_hosts and ensure no system level ssh configuration disables host key checking for that host then use the following pyproject.toml

[tool.poetry]
name = "test"
version = "0.1.0"
description = ""
authors = [""]

[tool.poetry.dependencies]
poetry = { "git" = "[email protected]:python-poetry/poetry.git" }

poetry uses dulwich for git clones, so next step is to persuade dulwich to use that parameter then

suggest you experiment with something like

diff --git a/src/poetry/vcs/git/backend.py b/src/poetry/vcs/git/backend.py
index 0fc00f0b..b3b28026 100644
--- a/src/poetry/vcs/git/backend.py
+++ b/src/poetry/vcs/git/backend.py
@@ -194,7 +194,7 @@ class Git:
         client: GitClient
         path: str

-        kwargs: dict[str, str] = {}
+        kwargs = {"ssh_command": "ssh -o BatchMode=yes"}
         credentials = get_default_authenticator().get_credentials_for_git_url(url=url)

         if credentials.password and credentials.username:

and submit a merge request if you can get it to work satisfactorily

That isn't the only "failure case" for this though, the bug is that the "Resolving dependencies" message erases messages from the SSH client. E.g. if you are prompted to type in your passphrase to unlock your ssh key, that message gets erased and unless you notice the message flash for an instant and realize what it is, you'll spend hours trying to figure out why adding a git+ssh dependency suddenly starts making dependency resolution take forever. In other words, the messaging that it's resolving dependencies isn't actually accurate and overwriting the prompt that would allow it to proceed obscures what the user needs to do.

(In other words, dulwich seems to be doing the right thing, if only Poetry didn't overwrite the prompts.)

That isn't the only "failure case" for this though, the bug is that the "Resolving dependencies" message erases messages from the SSH client. E.g. if you are prompted to type in your passphrase to unlock your ssh key, that message gets erased and unless you notice the message flash for an instant and realize what it is, you'll spend hours trying to figure out why adding a git+ssh dependency suddenly starts making dependency resolution take forever. In other words, the messaging that it's resolving dependencies isn't actually accurate and overwriting the prompt that would allow it to proceed obscures what the user needs to do.

(In other words, dulwich seems to be doing the right thing, if only Poetry didn't overwrite the prompts.)

My issue, mentioned here before (#9626) also reports this. It also looks to me that several people in the issues section actually have this as the root of their "hanging" bugs.

My issue was closed but not fixed, I do wonder, is this something that won't be fixed?

I've been working around this by just watching closely, you can see the prompt for a fraction of a second, before the counter over-writes it, then you know what to do (ie enter a password to decrypt your private key).

I love poetry but perhaps maintainers are not seeing these issues because they are auto-closed?

Edit: I see now that my issue was closed as "not planned", so indeed it will be confusion for anyone who uses Git over SSH with an encrypted private key, right? Am I missing something?

your issue was correctly closed because it is a duplicate of this one, there is no value in having both. This one is still open.

there is a pull request at #9638 which imo was over-complicating matters but either way looks abandoned.

I expect something that plumbs BatchMode=yes through to dulwich - whether by an environment variable or by explicit arguments or whatever - would be welcome.

Oh yes I see the label "duplicate" indeed, thanx.

The UX to address this is still up in the air. I think the only real insight I've had since the discussion on the PR is that having this functionality linked to verbosity level seems more cursed the more I think about it.

I still think pausing the timer output during the git command is the best option, it should essentially handle all cases correctly for a relatively small negative impact on non CI/CD users with git dependencies that result in long running, non interactive git commands.

The above assumes CI/CD users are not watching the console output in real time which is probably an imperfect assumption.

Other solutions, BatchMode=yes or otherwise, all get into the issue that it shifts the burden on the user from "know how git/ssh works" to "know how poetry works". e.g. Permission denied (publickey,password)., even if it's surfaced to the user correctly, won't indicate to most users that the key has a passphrase. My first debugging step would be to set SSH_COMMAND=ssh -v which would either disable batch mode or do nothing with the discussed implementation; both of which would have very confusing results. I'm taking it for granted that trying to compose together multiple ssh_command settings in a remotely reasonable way is an unreasonable amount of complexity.