fatal: could not read Username for 'https://github.com': No such device or address

[CraigRegester]

Appears to be an issue in the WebUIDriver.cls with HSUCR 2021.2. Clicking the refresh button next to the remote branches in the Git Web UI leads to this error (though if I run a fetch from the Source Control menu, that works fine)

fatal: could not read Username for 'https://github.com': No such device or address

Opened up the Developer Tools in the browser and I see this:

Form Data:
fetch --prune

Response:
fatal: could not read Username for 'https://github.com': No such device or address

Git-Stderr-Length: 83
Git-Return-Code: 128

Those latter two lines led me to WebUIDriver.cls as they're in the HandleRequest ClassMethod.

Not clear what path it is inspecting to determine the if/elseif logic in that method but happy to give more info if I know what I'm after. I think it may be this but unsure:

POST /ucr/isc/studio/usertemplates/gitsourcecontrol/webuidriver.csp/MYLIB/MYUCR.Productions.MYLIB.CLS/git HTTP/1.1

[isc-svelury]

Do you have SSH remotes configured?

If not, this could be happening because it looks for a way for the user to enter a password but can't find one. This SO post explains it better: https://stackoverflow.com/questions/40274484/fatal-could-not-read-username-for-https-github-com-device-not-configured?noredirect=1&lq=1

I am not sure why it works from the Source Control menu but not from the WebUI. I will have to look at that in more detail.

[CraigRegester]

Hmm yea it's the latter part that threw me off but it may be because my 'cacheusr' 's local .gitconfig has a credential helper now that I think about it (byproduct of me rolling by own for awhile) - and maybe the Web GUI isn't respecting it. But that's a-ok - you're probably spot on, so let me check my remote setup and I'll close this out if so.

[isc-svelury]

In our testing, regardless of whether a user has a credential helper, something that requires interaction with the remote does not reliably work with HTTPS based authentication.

fetch from the SourceControl menu seemed to work either way but push and pull never did (which is consistent with what you observed). I don't think we ever figured out why it behaves that way.

That's why we recommend using SSH for any interaction with the remote repository.

A note on the SSH remote setup: Depending on how your firewall is configured, the SSH URL from GitHub might not work even after you have the keys set up correctly. In that case, these steps worked for me and Tim:

Try ssh -T -p 443 [email protected] and see if it works. Your user should be authenticated. Something like this:

Hi <owner-name>/<repository-name>! You've successfully authenticated, but GitHub does not provide shell access.

If this works, then change the URL of your remote to be ssh://[email protected]:443/<owner-name>/<repository-name>.git

[isc-tleavitt]

In terms of authentication modes, I do think we'll want to (sooner or later) support the approach that @CraigRegester graciously gave us some code for in addition to ssh.

[CraigRegester]

That was it - I had a special credential heloer built (it's in my code @isc-tleavitt mentioned) that would pull the OAuth access token from a global and connect, so explains why it partially worked. (I removed this credential helper from cacheusr's .gitconfig to take it out of any further issue equations.)

Unfortunately not entirely out of the woods though just yet.... on the command line, I had to do the following to get the remote added:

/hfs/sys/git/IRISHealth$ git config core.sshCommand "ssh -i /hfs/sys/git/dpk_i4h_ed25519 -F /dev/null"
/hfs/sys/git/IRISHealth$ git remote add origin -f -m dev ssh://[email protected]:443/MyOrg/ISC-IRISHealth.git
Updating origin
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (6/6), 2.01 KiB | 171.00 KiB/s, done.
From ssh://ssh.github.com:443/MyOrg/ISC-IRISHealth
 * [new branch]      dev        -> origin/dev
 * [new branch]      prod       -> origin/prod
 * [new branch]      test       -> origin/test

That's all well and good. So I jump to the Web UI in the Management Portal to try and checkout the dev branch.... And it gives this error now"

command-line line 0: unsupported option "accept-new".
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

DevTools show it's trying to do

fetch origin dev
undefined <---?

followed by
checkout -b dev origin/dev <--- this part seemed to work...

The only thing I have in the repo right now is a README.md and I can see it pulled down so it did work somewhat. But the error is definitely not very nice.

[isc-svelury]

Just to confirm, have you updated the path to your private key in the Settings page?

Additionally do you have OpenSSH >= 7.6?

The accept-new option for StrictHostKeyChecking was added in 7.6 (release notes). We use it here to automatically accept new keys.

[CraigRegester]

Yes on the private key.

OpenSSH 7.5p1 :(

I see 8.1.x is available for AIX 7.2 so I'll inquire with my system guys if they have any concerns upgrading

[isc-tleavitt]

@isc-svelury let's just document the OpenSSH requirement and call it a day on this one.