![]() ![]() ![]() After a few minutes they returned to the call. Changing DNS servers should have that kind of impact. Once they did that, they vanished off the virtual call, and I felt a moment of concern. We tried to fix that by changing their DNS Servers to OpenDNS. Same problem.Ĭonsidering we were having a virtual meeting that seemed odd as they were connected to the internet, but it seemed like their DNS servers were having issues. I then had them test to see if they could ping. For some reason their system could not resolve the hostname. I then had them see if they could ping from their dev environment. ![]() Everything on their status page reported as normal, and again everyone else on the team could push/pull/create/clone/etc. Obviously the first thing was to look at the status page for GitHub as there have been times when GitHub has various systems attacked. Considering this was the second time for this particular client, I figured I needed to look deeper. Usually when running into an error when working with an application, the tendency is to land the error squarely on the shoulders of the app failing in some way. ![]() This time however, I decided to dig a bit deeper. Again, I reached out to some fellow GK Ambassadors to discuss the issue. I had a hard time believing that this instance had corrupted as well, even though it was the same client's team member. Then, two weeks ago, we ran into the same issue. Nothing had changed on their system during this time except for us making changes to the code in the project they were working on.Īfter some deliberation with other amazing GitKraken Ambassadors, we figured out that the GK install was probably corrupt, so we fully deleted and reinstalled it on that team member's system. The repos were there, could be accessed by others on the team, but this one individual. We checked to make sure GitHub wasn't running into one of their occasional issues. Generate new SSH keys using GitKraken 8.0.1, or later, for each of your Git service providers.There are a lot of different articles out there suggesting fixes for this specific issue including checking the firewall or using https instead of ssh, but everything had been fine until just that moment. Remove all old GitKraken-generated SSH keys stored locally.Ģ. Users who are not sure what version they used to generate their SSH key, are recommended to renew the key by doing the following:ġ. However, the GitKraken team has warned that users who upgraded to a new version will still need to replace their GitKraken generated keys if they were generated in the affected versions. The vulnerability was fixed with the release of GitKraken 8.0.1. A remote attacker can generate duplicate SSH keys and gain unauthorized access to the affected systems. The vulnerability exists due to an error in the pseudo-random number generator used by keypair to generate RSA keys for SSH connections. The bug, which was discovered in late September by the GitKraken team, resides in the open source SSH key generation library that was implemented in GitKraken versions 7.6.x, 7.7.x, 8.0.0, released between 5-12-21 and 9-27-21. The decision to revoke SSH keys was made after GitKraken engineering team contacted Git hosting service providers about the issue. Microsoft Azure DevOps, GitHub, GitLab, and BitBucket, four of the largest code hosting portals to date, have all issued a mass recall of SSH keys following a report about a vulnerability in GitKraken, a popular Git software client. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |