Today, we’re announcing some changes that will improve the security of accessing Git data over SSH.

What’s changing?

We’re adding a new post-quantum secure SSH key exchange algorithm, known alternately as sntrup761x25519-sha512 and sntrup761x25519-sha512@openssh.com, to our SSH endpoints for accessing Git data.

This only affects SSH access and doesn’t impact HTTPS access at all.

It also does not affect GitHub Enterprise Cloud with data residency in the United States region.

Why are we making these changes?

These changes will keep your data secure both now and far into the future by ensuring they are protected against future decryption attacks carried out on quantum computers.

When you make an SSH connection, a key exchange algorithm is used for both sides to agree on a secret. The secret is then used to generate encryption and integrity keys. While today’s key exchange algorithms are secure, new ones are being introduced that are secure against cryptanalytic attacks carried out by quantum computers.

We don’t know if it will ever be possible to produce a quantum computer powerful enough to break traditional key exchange algorithms. Nevertheless, an attacker could save encrypted sessions now and, if a suitable quantum computer is built in the future, decrypt them later. This is known as a “store now, decrypt later” attack.

To protect your traffic to GitHub when using SSH, we’re rolling out a hybrid post-quantum key exchange algorithm: sntrup761x25519-sha512 (also known by the older name sntrup761x25519-sha512@openssh.com). This provides security against quantum computers by combining a new post-quantum-secure algorithm, Streamlined NTRU Prime, with the classical Elliptic Curve Diffie-Hellman algorithm using the X25519 curve. Even though these post-quantum algorithms are newer and thus have received less testing, combining them with the classical algorithm ensures that security won’t be weaker than what the classical algorithm provides.

These changes are rolling out to github.com and non-US resident GitHub Enterprise Cloud regions. Only FIPS-approved cryptography may be used within the US region, and this post-quantum algorithm isn’t approved by FIPS.

When are these changes effective?

We’ll enable the new algorithm on September 17, 2025 for GitHub.com and GitHub Enterprise Cloud with data residency (with the exception of the US region).

This will also be included in GitHub Enterprise Server 3.19.

How do I prepare?

This change only affects connections with a Git client over SSH. If your Git remotes start with https://, you won’t be impacted by this change.

For most uses, the new key exchange algorithm won’t result in any noticeable change. If your SSH client supports sntrup761x25519-sha512@openssh.com or sntrup761x25519-sha512 (for example, OpenSSH 9.0 or newer), it will automatically choose the new algorithm by default if your client prefers it. No configuration change should be necessary unless you modified your client’s defaults.

If you use an older SSH client, your client should fall back to an older key exchange algorithm. That means you won’t experience the security benefits of using a post-quantum algorithm until you upgrade, but your SSH experience should continue to work as normal, since the SSH protocol automatically picks an algorithm that both sides support.

If you want to test whether your version of OpenSSH supports this algorithm, you can run the following command: ssh -Q kex. That lists all of the key exchange algorithms supported, so if you see sntrup761x25519-sha512 or sntrup761x25519-sha512@openssh.com, then it’s supported.

To check which key exchange algorithm OpenSSH uses when you connect to GitHub.com, run the following command on Linux, macOS, Git Bash, or other Unix-like environments:

$ ssh -v git@github.com exit 2>&1 | grep 'kex: algorithm:'

For other implementations of SSH, please see the documentation for that implementation.

What’s next?

We’ll keep an eye on the latest developments in security. As the SSH libraries we use begin to support additional post-quantum algorithms, including ones that comply with FIPS, we’ll update you on our offerings.

The post Post-quantum security for SSH access on GitHub appeared first on The GitHub Blog.

What’s changing?

We’re changing which algorithms and keys are supported in SSH and disabling the unencrypted Git protocol. Specifically, we are:

• Removing support for all DSA keys
• Adding requirements for newly-added RSA keys
• Removing the HMAC-SHA-1 algorithm
• Allowing administrators to enable Ed25519 host keys
• Turning off the unencrypted Git protocol

These changes will be included in GitHub Enterprise Server 3.6.

Only users connecting via SSH or git:// are affected. If your Git remotes start with https://, nothing in this post will affect you. If you’re an SSH user, read on for the details and timeline.

Why are we making these changes?

Cryptography depends on secure algorithms and sufficiently strong keys to remain secure. “Fewer bits” generally means “easier to brute force,” and older algorithms have known attacks. What was considered secure in, say 2001, might no longer be acceptable today given changes in computing power, new attacks, and so on.

In this case, we’re moving away from DSA and SHA-1 to make sure that the algorithms we ship are secure and robust. Similarly, the unencrypted Git protocol doesn’t provide privacy, integrity, or authenticity, like the HTTPS and SSH protocols do. As of GHES 3.6, the unencrypted Git protocol is deprecated and defaults to off.

How is this different from the changes that have been made to GitHub.com?

Most of the changes are the same. However, in this case, we’ve also made some of the changes configurable for GitHub Enterprise Server administrators who have different needs.

• First, administrators can configure the cut-off date for RSA keys using SHA-1, which defaults to midnight August 1, 2022, UTC. Keys uploaded after that date (or a date that they’ve chosen) will need to use RSA with SHA-2. Administrators can also choose to disable all use of RSA with SHA-1, if their environment is ready for that.
• While Ed25519 keys will be advertised automatically with OpenSSH-style host key rotation, administrators will need to specifically enable the use of the Ed25519 key for production use to avoid host key warnings on certain non-OpenSSH software.
• Finally, the unencrypted Git protocol will be disabled by default, but can be re-enabled by the administrator, if they’d like to do that.

In all these cases, we’ve chosen to provide a secure default. We understand that this may be surprising or even disruptive in some environments, so we’ve balanced those defaults with options to maximize customizability.

How do I verify that I’m ready?

In GitHub Enterprise Server 3.4 and newer, we’ve included a program called ghe-find-insecure-git-operations. It will print out any log lines that indicate the use of an insecure algorithm, which you can then investigate. However, by default, it ignores log entries where we know that the client would automatically upgrade to a more secure algorithm once the insecure configuration is disabled, in order to avoid needless noise.

If you’re using OpenSSH 7.2p2 or later, PuTTY 0.75 or later, or a Go SSH client from March 15 or later, then you should be fine if you’re not using DSA client keys. In our testing, DSA client keys are very rare and have not been the default in any SSH client for well over a decade, so most people will have a different key type instead.

We expect most people using a recent version of OpenSSH from Git for Windows, macOS, or a Linux distribution released in the past five years should have no problems.

What’s next?

We’re always keeping an eye on the latest developments in security, attacks in the wild, and use of features in order to keep the GitHub community secure. We’ll continue to watch RSA with SHA-1 usage on GitHub.com and listen to GitHub Enterprise servers about their usage of the Git protocol. Once they decline, naturally, we’ll update the community on plans to fully deprecate these features.

The post Improving Git protocol security on GitHub Enterprise Server appeared first on The GitHub Blog.

What’s changing?

We’re changing which keys are supported in SSH and removing unencrypted Git protocol. Specifically we are:

• Removing support for all DSA keys
• Adding requirements for newly added RSA keys
• Removing some legacy SSH algorithms (HMAC-SHA-1 and CBC ciphers)
• Adding ECDSA and Ed25519 host keys for SSH
• Turning off the unencrypted Git protocol

Only users connecting via SSH or git:// are affected. If your Git remotes start with https://, nothing in this post will affect you. If you’re an SSH user, read on for the details and timeline.

We recently removed support for passwords over HTTPS. These SSH changes, while unrelated on a technical level, are part of the same drive to keep GitHub’s customer data as secure as possible.

Why are we making these changes?

Public key cryptography depends on secure algorithms and sufficiently strong keys to remain secure. “Fewer bits” generally means “easier to brute force,” and older algorithms have known attacks. What was considered secure in, say 2001, might no longer be acceptable today given changes in computing power, new attacks, and so on.

Dropping old key types

DSA keys offer only an 80-bit security level. This is low (128-bit is fairly standard), and fewer than 0.3% of GitHub requests are still using DSA. We feel confident that rejecting these keys altogether will increase security with little or no user friction. We’re also planning to remove support for our DSA host key.

Dropping insecure signature algorithms

RSA keys (you’ll see ssh-rsa in the public key) are stronger than DSA keys, but older Git clients may use them in combination with a dated signature algorithm that uses SHA-1. Many SSH clients, including OpenSSH 7.2 and newer, support RSA with SHA-2 signatures (signature types rsa-sha2-256 and rsa-sha2-512), which are secure. However, other clients only support the older SHA-1 signatures. SHA-1 is weak, so we’ll stop allowing new RSA client keys to use SHA-1 signatures and require them to use SHA-2 signatures instead. Keys with a valid_after date before the deadline (November 2, 2021) may continue to use SHA-1 signatures for the time being.

Dropping insecure algorithms

There are additional algorithms we’ll be removing for our SSH service. The hmac-sha1 message authentication code will be removed, as will all CBC ciphers (aes256-cbc, aes192-cbc, and aes128-cbc). The CBC ciphers in particular are known to be relatively practical to attack, and our data shows that almost all clients offer better encryption and MAC algorithms.

New host keys

ECDSA and Ed25519 are newer standards based on elliptic curve cryptography. They offer good security characteristics for modest size and computation increases. GitHub hasn’t traditionally offered these as host keys (server keys), but we’ll be offering them as options in the future. We’ll be shipping them in advance using OpenSSH’s UpdateHostKeys extension, which uses a secure technique to prove that GitHub owns the new keys it’s proposing. The new host key fingerprints for these keys are as follows:

• ECDSA: SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM
• Ed25519: SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU

The actual host keys are these: ecdsa-sha2-nistp256 AAAAE2VjZHNhL

• ECDSA:

  ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=

• Ed25519:

  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl

No more unauthenticated Git

On the Git protocol side, unencrypted git:// offers no integrity or authentication, making it subject to tampering. We expect very few people are still using this protocol, especially given that you can’t push (it’s read-only on GitHub). We’ll be disabling support for this protocol.

When are these changes effective?

How do I prepare?

Again, only users connecting via SSH or git:// are affected. If your Git remotes start with https://, nothing here will affect you.

Standard Git client

If you’re running Git from the command line and using OpenSSH, make sure that you’re using OpenSSH 7.2 or newer, which you can verify with ssh -V. You can also use OpenSSH versions as old as 6.5 with Ed25519 keys or 5.7 with ECDSA keys. We’ve also provided a helpful script in this repository, which you can run to verify that your keys are properly configured. Also, we recommend adding the following configuration stanza to your ~/.ssh/config:

Host github.com
    UpdateHostKeys yes

If you’re using PuTTY with Git, make sure you’ve upgraded to 0.75 or newer, which you can check with putty --version.

libgit2 and other Git clients

If you’re using libgit2 or another piece of code using libssh2, we recommend you use libssh2 1.9.0 or newer and an ECDSA key, since it does not yet support RSA with SHA-2. Similarly, the Go SSH client also doesn’t yet support RSA with SHA-2, so we recommend using an Ed25519 key there.

Check your keys

Make sure that you’re ready to accept our new host keys. You can check the fingerprints above and save the keys in a place suitable for your SSH client.

If you’re using a DSA (ssh-dss) public key, regenerate and upload a new SSH key, such as an Ed25519 key.

What should I do if things are broken after this change?

SSH troubleshooting

If SSH was working before the change and fails afterward, you may be using an older operating system or have older SSH libraries. You can get detailed information about GitHub’s supported SSH algorithms and what your client presents by running ssh -vvv git@github.com. If your client is trying to negotiate one of the deprecated key types or fingerprint types, you may need to create a new SSH key and upload it to GitHub.

Clients relying on older SSH implementations will need to be updated. (The standard Git client uses your operating system’s SSH implementation on Linux and macOS.) Common examples include:

• OpenSSH before version 7.2
• PuTTY before 0.75

GitHub has worked with these vendors to make new versions of their packages available.

CentOS 6 and Ubuntu 14.* ship with old versions of OpenSSH. While you may be able to upgrade them to a newer OpenSSH version, note that these operating systems are end-of-life and thus unsupported by GitHub.

Git protocol troubleshooting

If you’re having trouble cloning a repository, make sure the URL starts with ssh://, https://, or git@github.com.

For existing repositories, if you’re having trouble fetching, check that the remote you are fetching from is an ssh:// or https:// URL, or an SSH pseudo-URL starting with git@github.com. You can run git remote -v in the repository to see the URLs for all remotes. If any of them start with git://, you should change the URL to a supported format.

What’s next?

We’re always keeping an eye on the latest developments in security, attacks in the wild, and use of features in order to keep the GitHub community secure. We’ll continue to watch RSA with SHA-1 usage. Once it declines naturally, we’ll update the community on plans to deprecate it.

The post Improving Git protocol security on GitHub appeared first on The GitHub Blog.