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 [email protected], 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 [email protected]). 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 [email protected] 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 [email protected], 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 [email protected] 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 [email protected]. 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 [email protected].

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 [email protected]. 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.

What are security keys and how do they work?

Security keys, such as the YubiKey, are portable and transferable between machines in a convenient form factor. Most security keys connect via USB, NFC, or Bluetooth. When used in a web browser with two-factor authentication enabled, security keys provide a strong, convenient, and phishing-proof alternative to one-time passwords provided by applications or SMS. Much of the data on the key is protected from external access and modification, ensuring the secrets cannot be taken from the security key. Security keys should be protected as a credential, so keep track of them and you can be confident that you have usable, strong authentication. As long as you retain access to the security key, you can be confident that it can’t be used by anyone else for any other purpose.

Use your existing security key for Git operations

When used for SSH operations, security keys move the sensitive part of your SSH key from your computer to a secure external security key. SSH keys that are bound to security keys protect you from accidental private key exposure and malware. You perform a gesture, such as a tap on the security key, to indicate when you intend to use the security key to authenticate. This action provides the notion of “user presence.”

Security keys are not limited to a single application, so the same individual security key is available for both web and SSH authentication. You don’t need to acquire a separate security key for each use case. And unlike web authentication, two-factor authentication is not a requirement when using security keys to authenticate to Git. As always, we recommend using a strong password, enrolling in two-factor authentication, and setting up account recovery mechanisms. Conveniently, security keys themselves happen to be a great recovery option for securely retaining access to your two-factor-enabled account if you lose access to your phone and backup codes.

The same SSH keys you already know and love, just a little different

Generating and using security keys for SSH is quite similar to how you generated and used SSH keys in the past. You can password-protect your key and require a security key! According to our data, you likely either use an RSA or ed25519 key. Now you can use two additional key types: ecdsa-sk and ed25519-sk, where the “sk” suffix is short for “security key.”

$ ssh-keygen -t ecdsa-sk -C <email address> 
Generating public/private ecdsa-sk key pair. 
You may need to touch your authenticator to authorize key generation.

Once generated, you add these new keys to your account just like any other SSH key. You’ll still create a public and private key pair, but secret bits are generated and stored in the security key, with the public part stored on your machine like any other SSH public key. There is a private key file stored on your machine, but your private SSH key is a reference to the security key device itself. If your private key file on your computer is stolen, it would be useless without the security key. When using SSH with a security key, none of the sensitive information ever leaves the physical security key device. If you’re the only person with physical access to your security key, it’s safe to leave plugged in at all times.

Safer Git access and key management

With security keys, you can achieve a higher level of account security and protection from account takeover. You can take things a step further by removing your previously registered SSH keys, using only SSH keys backed by security keys. Using only SSH keys backed by security keys gives you strong assurance that you are the only person pulling your Git data via SSH as long as you keep the security key safe like any other private key.

Security keys provide meaningful safety assurances even if you only access Git on trusted, consistent systems. At the other end of the spectrum, you might find yourself working in numerous unfamiliar environments where you need to perform Git operations. Security keys dramatically reduce the impact of inadvertent exposure without the need to manage each SSH key on your account carefully. You can confidently generate and leave SSH keys on any system for any length of time and not have to worry about removing access later. We’ll remove unused keys from your account, making key management even easier. Remember to periodically use keys you want to retain over time so we don’t delete them for you.

Protecting against unintended operations

Every remote Git operation will require an additional key tap to ensure that malware cannot initiate requests without your approval. You can still perform local operations, such as checkout, branch, and merge, without interruption. When you’re happy with your code or ready to receive updates, remote operations like push, fetch, and pull will require that you tap your security key before continuing. As always, SSH keys must be present and optionally unlocked with a password for all Git operations. Unlike password-protected SSH keys, clients do not cache security key taps for multiple operations.

$ git clone [email protected]:github/secure_headers.git
Cloning into 'secure_headers'...
Confirm user presence for key ECDSA-SK SHA256:xzg6NAJDyJB1ptnbRNy8UxD6mdm7J/YBdu2p5+fCUa0
User presence confirmed

Already familiar with using SSH keys backed by security keys? In that case, you might wonder why we require verification (via the security key “tap”) when you can configure your security key to allow operations to proceed as long as the security key is present. While we understand the appeal of removing the need for the taps, we determined our current approach to require presence and intention is the best balance between usability and security.

Towards a future with fewer passwords

Today, you can use a password, a personal access token (PAT), or an SSH key to access Git at GitHub. Later this year, as we continue to iterate toward more secure authentication patterns, passwords will no longer be supported for Git operations. We recognize that passwords are convenient, but they are a consistent source of account security challenges. We believe passwords represent the present and past, but not the future. We would rather invest in alternatives, like our Personal Access Tokens, by adding features such as fine-grained access and more control over expiration. It’s a long journey, but every effort to reduce the use of passwords has improved the security of the entire GitHub ecosystem.

By removing password support for Git, as we already successfully did for our API, we will raise the baseline security hygiene for every user and organization, and for the resulting software supply chain. By adding SSH security key support, we have provided a new, more secure, and easy-to-use way to strongly authenticate with Git while preventing unintended and potentially malicious access. If you are ready to make the switch, log in to your account and follow the instructions in our documentation to create a new key and add it to your account.

We wanted to extend our gratitude to Yubico, with whom we’ve partnered several times over the years, for being an early collaborator with us on this feature and providing us valuable feedback to ensure we continue to improve developer security.

The post Security keys are now supported for SSH Git operations appeared first on The GitHub Blog.

How is this different than an SSH key?

If you’re wondering how an SSH certificate is different than an SSH key you’re not alone. GitHub has supported SSH keys—cryptographic keys that securely identify individual users—from the very beginning. But SSH also has a specification that defines support for SSH certificates. SSH certificates allow one SSH key to sign another SSH key, resulting in an “SSH certificate”. A server that trusts the CA is able to verify the certificate’s signature and trust the certificate and its associated metadata.

How does it work?

To get a sense for how it all works and gives teams more control, let’s take a look at how an organization would set up their CA before signing keys. The configuration process for enterprises is very similar.

First, an organization uploads their SSH CA key. This is just a normal SSH key:

➜  ssh-keygen -t ed25519 -C [email protected] -f ca
➜  cat ca.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOixUTX9ssW7bAaO6wTxXxJGRpVWNnqnOFwFZ1ceOxVn [email protected]

An organization uploads the public key similar to how they would for a user’s normal SSH key. But, instead, they upload the public key to their organization’s “SSH Certificate Authorities” configuration page:

Note: Enterprises and organizations can require SSH certificates to access their repositories. This gives admins more control over which keys can be used to access their repositories. Once uploaded, members will have a new section in their SSH key management page to see the enterprises and organizations they belong to that have an SSH CA configured.

Once an organization has added their SSH CA, they can begin to issue certificates to access the organization’s repositories. For the sake of simplicity, let’s use a user’s normal SSH key as an example:

➜  ssh-keygen -t ed25519 -C [email protected] -f user1
➜  cat user1.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGN4i6n6N2jdOXM1RUhLIcww1RnO6QaE3psgUXLewash [email protected]

This key can now be signed by the SSH CA to create a certificate used to access repositories owned by the organization:

➜ ssh-keygen -O extension:[email protected]=user1 -s ca -V '+1d' -I [email protected] -n user1 user1.pub
Signed user key user1-cert.pub: id "[email protected]" serial 0 for user1 valid from 2019-08-09T12:26:00 to 2019-08-10T12:27:43

Individual SSH keys no longer need to be uploaded to a developer’s account to access organization repositories. If an SSH key has been signed by the CA key, the resulting certificate can be used to authenticate access to organization repositories. GitHub identifies the developer accessing the repository based on the “[email protected]” certificate extension, which must be included.

SSH certificates allow organizations to maintain sophisticated security policies, such as certificates that expire daily. The certificate we created in our example has an expiration of one day. Organizations can establish highly secure development workflows where, every morning, a developer fetches their daily certificate from a custom internal system or a readily available solution that is responsible for issuing them. This system can perform whatever authentication abides by the internal authentication requirements of that organization. The resulting certificate can be used to do all of a developer’s work on GitHub.com for the day. And at the end of the day, the certificate automatically expires, and the developer is no longer be able to access any of that organization’s repositories. 

This is a highly requested feature from some of the most security-conscious teams around the world. We’re glad to give them—and all of the teams who use GitHub Enterprise—more ways to keep their code safe. And stay tuned: SSH certificate authentication support for Enterprise Server is coming soon.

Learn more about certificate authentication for GitHub Enterprise

The post SSH certificate authentication for GitHub Enterprise Cloud appeared first on The GitHub Blog.

You’re in control

As always, when an application requests access to your account, you get to decide whether to grant that access or not.

Revoke with ease

In addition to these finer-grained permissions, we’re also making it easier to revoke SSH access to your data. If an OAuth application creates an SSH key in your account, we’ll automatically delete that key when you revoke the application’s access.

To help you track security events that affect you, we’ll still email you any time a new key is added to your account. And of course, you can audit and delete your SSH keys any time you like.

You can read about the new changes in more detail on the GitHub Developer site.

The post Enhanced OAuth security for SSH keys appeared first on The GitHub Blog.