ataylor What operating system(s) are you testing on? Are you sure this isn't just a quirk of your local ssh setup? For example, on macOS, by default it looks like the git plugin is trying to read my ssh passphrase from stdin, rather than using the credentials in Jenkins, but I think that is an macOS-specific quirk (and I have not yet found a way to make it work).

Can you provide more details of the configuration where you've seen the problem?

I run passphrase protected ssh private keys frequently in my regression testing environments with Windows, CentOS, Debian, Ubuntu, and some FreeBSD. I've not detected specific problems, though I've also not performed an exhaustive test of all configurations and all alternatives.

There was a report that clone with command line git 2.17 and later on Windows may hang with passphrase protected private keys, while clone with command line git 2.9.3 on Windows was successful.

Are you using a passphrase which includes a character that is special to the shell (like '*' or '$')? If so, that is a known problem. Command line git uses ssh for its private key authentication. Ssh expects to receive the passphrase from stdin. The plugin provides it from stdin with a shell script that uses the `echo` command. The `echo` command performs shell expansion on its arguments. Thus, shell special characters are not allowed in a passphrase with the git plugin. A pull request is pending which resolves that, but it is not ready for production.

markewaitednusbaum
This is MacOS and I see the same behavior as the customer who was running on windows

>Are you using a passphrase which includes a character that is special to the shell

Password was `testing` in my case

I have not tried in Linux yet but I can certainly do it if you like. Could I attach a bundle of my instance where I reproduced so you can spin up a copy?

ataylor What is the error message you are seeing, and what credentials type are you using in Jenkins (username/password, ssh username w/ private key, etc.)? I was able to get things working on a Linux machine, and can try again on Windows shortly.

A bundle would be fine. After seeing this report, I ran passphrase based tests on Windows and Linux with different versions of command line git. All of them passed. I don't have a macOS machine available.

The closest I have to macOS is my FreeBSD machine and it uses a passphrase protected private key as well as my Linux and Windows machines.

Is your Jenkins server process or agent process running in the foreground? Meaning, was it started from a shell prompt and is still running from a shell prompt? JNLP agents might be started that way. Docker-based servers are commonly started that way.

OpenSSH will prompt for interactive input of the passphrase if it detects a terminal attached to its standard input.

The workaround for the agent is to prefix the JNLP start command with `setsid`. That detaches the terminal. OpenSSH won't see a terminal and thus won't prompt.

markewaite Thanks for the pointer, I used https://github.com/jerrykuch/ersatz-setsid to run a JNLP agent on macOS using setsid and am no longer seeing errors on macOS using a credential of type 'SSH Username w/ Private Key' in Jenkins.

dnusbaum there is a setting in the git plugin which will prefix every command line git call with `setsid` (on platforms where a setsid program is available). However, it is a system property and not readily available to typical users.