I’m trying to set up my Fedora 43 Workstation for the first time, and one of the hurdles I’m hitting is getting a GitHub connection working for my git repos. The weird thing is that I was able to set up my SSH key and clone successfully for the first time. But afterwards, all my git pull or git push commands hang. When I run ssh -T git@github.com it hangs indefinitely.
debug1: OpenSSH_10.0p2, OpenSSL 3.5.4 30 Sep 2025
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug1: Reading configuration data /etc/ssh/ssh_config.d/30-libvirt-ssh-proxy.conf
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
debug1: Reading configuration data /etc/ssh/ssh_config.d/30-libvirt-ssh-proxy.conf
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to github.com [140.82.112.4] port 22.
debug1: Connection established.
debug1: identity file /home/bluu/.ssh/id_rsa type -1
debug1: identity file /home/bluu/.ssh/id_rsa-cert type -1
debug1: identity file /home/bluu/.ssh/id_ecdsa type -1
debug1: identity file /home/bluu/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/bluu/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/bluu/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/bluu/.ssh/id_ed25519 type 3
debug1: identity file /home/bluu/.ssh/id_ed25519-cert type -1
debug1: identity file /home/bluu/.ssh/id_ed25519_sk type -1
debug1: identity file /home/bluu/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/bluu/.ssh/id_xmss type -1
debug1: identity file /home/bluu/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_10.0
debug1: Remote protocol version 2.0, remote software version 4b61ab4
debug1: compat_banner: no match: 4b61ab4
debug1: Authenticating to github.com:22 as 'git'
debug1: load_hostkeys: fopen /home/bluu/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:(removed)
debug1: load_hostkeys: fopen /home/bluu/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'github.com' is known and matches the ED25519 host key.
debug1: Found key in /home/bluu/.ssh/known_hosts:4
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa>
debug1: kex_ext_info_check_ver: publickey-hostbound@openssh.com=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: /home/bluu/.ssh/id_ed25519 ED25519 SHA256:(removed) agent
debug1: Will attempt key: /home/bluu/.ssh/id_rsa
debug1: Will attempt key: /home/bluu/.ssh/id_ecdsa
debug1: Will attempt key: /home/bluu/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/bluu/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/bluu/.ssh/id_xmss
debug1: Offering public key: /home/bluu/.ssh/id_ed25519 ED25519 SHA256:(removed) agent
debug1: Server accepts key: /home/bluu/.ssh/id_ed25519 ED25519 SHA256:(removed) agent
Some notes:
The connection to GitHub doesn’t seem to be an issue, since I can view it on the browser.
I’ve tried rebooting my router (as the other article suggests as the solution) but that didn’t work.
I’m able to make the problem go away temporarily if I regenerate the keys and reset them on GitHub, but that’s tedious and not a sustainable solution. I think that’s a hint but don’t know how to debug further.
My theory is that for whatever reason my SSH isn’t configured correctly or it expires the keys. But I’m new-ish to networking stuff so any help would be greatly appreciated.
I’ve tried that: I started ProtonVPN and it still hangs when I try ssh -T git@github.com.
Perhaps important, when I run htop I see that the ssh-add daemon is using the most CPU for some reason. Could it be that somehow I didn’t configure the SSH key correctly when I followed GitHub instructions to add it to the SSH agent? This is what I did: Using SSH agent forwarding - GitHub Docs
You do have a lot of keys being tried to connect to github, and each counting as a connection attempt, could it be that you hit some kind of maximum connection attempts allowed ?
Have you tried adding a section in your ~/.ssh/config that only presents the key(s) you actually use to connect to github ?
Note, because you provide the public key to the IdentityFile directive (which is originally meant for private keys), make sure that you make the public key accessible only to your user: chmod 600 ~/.ssh/my-github-key.pub.
Otherwise ssh is going to complain about too open permissions (even though it is a public key and would be just as secure with 644 permissions).
This is what the logs showed when I ran your commands:
Nov 15 14:19:31 main-framework packagekitd[3009]: Failed to get cache filename for libavcodec-free
Nov 15 14:20:33 main-framework dbus-broker[5676]: selinux/macstatus: avc: op=setenforce lsm=selinux enforcing=0 res=1
Nov 15 14:20:33 main-framework audit[2236]: AUDIT2313 pid=2236 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: op=setenforce lsm=selinux
enforcing=0 res=1 exe="/usr/bin/dbus-broker" hostname=? addr=? terminal=? res=success'
Given that the SSH test connection didn’t work, how can I “undo” those changes? As in, what set of commands resets my settings back to the original state? Is it just sudo setenforce 1?
I’m wondering if this is a network issue after all, because I had issues with the SSH test command on another Linux computer just now. But they don’t seem identical; sometimes that one works.
I will try the test connection outside of my network to see if I can pin it down to my network.
Hmmm, ssh-add is not the SSH agent, it is just the client application that communicates with the agent to add keys or list them (ssh-add -l). These are usually very short-lived and unless you start multiple at the same time, you should never really see multiple running on your system.
The fact that the processes stick around and consume so much CPU suggests to me that there is an issue with the communication with your SSH agent. What SSH agent are you using?
I think this is the SSH agent from Gnome keyring. It should be default on Workstation.
Whether it is correct depends. (I use a different SSH agent.) The fact that you get something when listing means that at least there is something listening on that socket.
Was that in a “clean” state or were there also a number of stuck ssh-add processes? Frankly, I am a bit surprised that you got a response, that contradicts my hypothesis that there is an issue with the SSH agent on your machine.
The next time you observe a bunch of these stuck ssh-add processes, can you please check if you can still list the identities in the agent with ssh-add -l?
Another thought, does your private key have a passphrase? Have you changed the SSH_ASKPASS environment variable?
Yes, my SSH key is password protected. I think it has something to do with my home network, I brought my Linux laptop to the library and it was able to connect to GitHub fine. I’ll investigate.
Another weird development. It works if I delete the old key and regenerate a new SSH key for GitHub. But upon a reboot it starts failing again. So somehow something changes (maybe a DNS setting) after some time and it stops working.
I don’t know if it’d be any help, but you’ve put only one -v in your command-line arguments; you might try adding two more for an even more verbose record of your interaction with the ssh server.
Maybe that would even give you clues on the timing of things related to your network, just in case that’s the source of your issue.
I keep coming back to the stuck ssh-add processes you see on your machine. This should not happen. I strongly suggest you approach the debugging from that angle before suspecting DNS.
Another thing you can try is using the OpenSSH agent, to see if your issue is connected to the Gnome keyring agent:
Note that this will only work in this shell, any other you open after that will have the default SSH_AUTH_SOCK set that points to the Gnome keyring agent, not the OpenSSH one.
Edit: ssh-add needs to add the private key, not the public key. I copied the filename from an earlier post and didn’t notice the .pub at the end
Thank you to everyone who responded. I followed Lars’ instructions and worked through adding my SSH keys to the ssh-add agent. It looks like they weren’t correctly added the first time. I think what happened was that I either tried to use the public key (which failed because it was expecting the private key) OR I gave it an incorrect passphrase and it silently failed (it happened a couple of times when I was trying it.
It tentatively works now so I’ll mark this as solved.
So, just to clarify for those of us reading your thread, you’re saying that you’ve modified your ~/.ssh/config file to point to the correct IdentifyFile for the private key you’re using instead of the pubic one you should’ve installed at github.com? And now when you add your key to the ssh-agent, everything is good?
I modified the config file to point to the public key, and I didn’t touch it when I tried fixing after. So I guess it still worked despite it being the public (rather than the private which I added to ssh-agent).
(I use a different SSH agent.) The fact that you get something when listing means that at least there is something listening on that socket.