cli: cannot authenticate through cli, with no error to debug on dnf(linux) based system

Describe the bug

problem: cannot authenticate through cli, with no error to debug:

❯ gh auth login -w

error connecting to github.com
check your internet connection or githubstatus.com

❯ gh --version
gh version 1.13.1 (2021-07-20)
https://github.com/cli/cli/releases/tag/v1.13.1

ID=fedora
VERSION_ID=34
VERSION_CODENAME=""
PLATFORM_ID="platform:f34"
~ ❯

Expected vs actual behavior

should login/or at least have verbose logging/error to understand what’s wrong

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 23 (7 by maintainers)

Most upvoted comments

I ran into this issue on Arch Linux. I had an empty /etc/resolv.conf, but dns lookups still worked across the system because it used systemd for dns resolution via nss. Go must not use the nss facility, so adding nameserver 1.1.1.1 to /etc/resolv.conf fixed the issue.

+61

drewkett on Feb 17, 2022

I figured it out for Arch Linux! I was using systemd-resolved for name resolution. I should have followed Arch Wiki to set up systemd-resolved to use the “stub mode”, in other words

ln -rsf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Compiling with cgo was rejected in https://bugs.archlinux.org/task/77057. Thank Mislav for help!

FranklinYu on Feb 17, 2023

This issue is discussed in detail here: https://wiki.archlinux.org/title/Systemd-resolved#DNS

TLDR; Not all programs use systemd’s resolved service and instead rely on /etc/resolv.conf.

The fix:

# ln -rsf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

DNS

Software that relies on glibc’s getaddrinfo(3) (or similar) will work out of the box, since, by default, /etc/nsswitch.conf is configured to use nss-resolve(8) if it is available.

To provide domain name resolution for software that reads /etc/resolv.conf directly, such as web browsers and GnuPG, systemd-resolved has four different modes for handling the file—stub, static, uplink and foreign. They are described in systemd-resolved(8) § /ETC/RESOLV.CONF. We will focus here only on the recommended mode, i.e. the stub mode which uses /run/systemd/resolve/stub-resolv.conf.

/run/systemd/resolve/stub-resolv.conf contains the local stub 127.0.0.53 as the only DNS server and a list of search domains. This is the recommended mode of operation that propagates the systemd-resolved managed configuration to all clients.

freddiehaddad on Oct 17, 2023

I figured it out for Arch Linux! I was using systemd-resolved for name resolution. I should have followed Arch Wiki to set up systemd-resolved to use the “stub mode”, in other words
ln -rsf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Very Thanks! That helped a lot

miakuon on Mar 1, 2023

I ran into this issue on Arch Linux. I had an empty /etc/resolv.conf, but dns lookups still worked across the system because it used systemd for dns resolution via nss. Go must not use the nss facility, so adding nameserver 1.1.1.1 to /etc/resolv.conf fixed the issue.

I’m on Arch too and this fixed it, thanks!

charbelnicolas on Jul 9, 2022

Run below commands to fix this: unset HTTP_PROXY unset HTTPS_PROXY unset http_proxy unset https_proxy

AmmeySaini on Aug 21, 2021

@ideepika Thanks for sharing! I can’t tell from over here why there would be a “server misbehaving” error message. Do you have a proxy set via https_proxy/HTTPS_PROXY environment variables or custom DNS server on this network? You can check DNS resolution with nslookup github.com or dig github.com. Also take a peek at /etc/resolv.conf.

I’m sorry, but people who don’t have access to your computer are not very well positioned to debug this issue. I think you might be able to get to the bottom of it after some digging, but I’m pretty sure that this is not a bug caused by gh. Closing until there is evidence that gh itself is broken.

mislav on Aug 5, 2021