Skip to content

ssh

Subscribe to all “ssh” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

SSH CA support for enterprise-owned user accounts

Enterprises that own their user accounts can now use SSH CAs to access user-owned repositories. This is an optional setting that enterprises can enable in their enterprise SSH CA settings page. Enabling this setting allows developers to use a single SSH certificate for all of their interactions with GitHub across their user account’s repositories and their enterprise’s repositories.

This is available now for customers using Enterprise Managed Users in GHEC, and will be included in GHES 3.14. It is not available to GHEC Classic enterprises, where developers bring their own personal accounts to the enterprise; the enterprise does not own those accounts and cannot gain access to their repositories.

For more about SSH certificate authorities, see “Managing SSH certificate authorities for your enterprise“.

See more

New SSH CAs must sign expiring certificates

SSH CAs uploaded to GitHub.com after March 27th, or in GHES 3.13 and beyond, can only sign certificates that expire. They must expire within 366 days of being created.
While expirations on certificates are not required by signing tools such as ssh-keygen, we are enforcing this best practice in order to protect against a weakness in how SSH certificates are linked to users.

CAs uploaded before the cutoff date or release will be marked in the UI as being allowed to sign non-expiring certificates:

image

An “upgrade” option on the CA lets you enforce expiration of signed certificates. Once you’ve validated that you are indeed using a lifetime on your certificates, we recommend upgrading your CAs. This upgrade step is irreversible, and new CAs cannot be downgraded to allow non-expiring certificates.
If a certificate is signed with no expiration, or a too-long expiration, it will be rejected during SSH connection with an error indicating The SSH certificate used was issued for a longer period than allowed.

This change forces the valid_after issuance timestamp to be written to the certificate, which allows GitHub to detect if the user changed their username after the certificate was issued for that username. This prevents a reuse attack vector where the former holder of a username is able to use certificates issued to them to sign in as the new holder of that username.

To learn more about managing SSH CAs, see “Managing your organization’s SSH CAs” and “Managing SSH CAs for your enterprise.” For information on using SSH CAs, see “About SSH CAs.”

See more

Removed unencrypted Git protocol and certain SSH keys

GitHub changed which keys are supported in SSH and removed the unencrypted Git protocol.
You can read more about the motivation behind these changes in our blog post from last September.
As a reminder, these changes were:

  • Removed all support for DSA keys
  • Required SHA-2 signatures on all RSA keys uploaded after November 2, 2021 (RSA keys uploaded prior to the cutoff may still use SHA-1 signatures)
  • Removed legacy SSH algorithms HMAC-SHA-1 and CBC ciphers
  • Permanently disabled the unencrypted Git protocol
See more

GitHub’s SSH host keys are now published in the API

The GitHub metadata endpoint now contains our SSH host keys.
(We'll continue offering host key fingerprints as well.)

{
  // new entry
  "ssh_keys": [
    "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl",
    "ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=",
    "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ=="
  ],
  // existing entry
  "ssh_key_fingerprints": [
    "SHA256_RSA": "nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8",
    "SHA256_ECDSA": "p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM",
    "SHA256_ED25519": "+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU"
  ],
  // ... rest of payload
}

These keys are in the OpenSSH known_hosts format for easy inclusion into existing known_hosts files.
This will make it easier to preconfigure systems which expect to connect via SSH.
For example, you can prime your CI runners with these keys before starting to fetch from GitHub.

The keys returned from the API include both SSH host keys that we're actively using, plus any that we're advertising via host key rotation for future use.
Currently, we're not offering any keys via rotation that aren't actively in use, but if we announce new host keys in the future, you can find them here as well during the rotation period.

See the meta API endpoint to learn more.

See more

SSH authentication with security keys

You can now authenticate to SSH using a FIDO2 security key by adding a sk-ecdsa-sha2-nistp256@openssh.com or sk-ssh-ed25519@openssh.com SSH key to your account. SSH security keys store secret key material on a separate hardware device that requires verification, such as a tap, to operate.

This combination of storing the key on separate hardware and requiring physical interaction for your SSH key offers additional security. Since the key is stored on hardware and is non-extractable, it can't be read or stolen by software running on the computer. Additionally, the tap prevents unauthorized use of the key since the security key will not operate until you physically interact with it.

Learn more about this feature from the accompanying blog post.

Learn more about adding an SSH key to your account.

See more