SSH

Using SSH agent forwarding
To simplify deploying to a server, you can set up SSH agent forwarding to securely use local SSH keys.
SSH agent forwarding can be used to make deploying to a server simple. 
It allows you to use your local SSH keys instead of leaving keys (without passphrases!) sitting on your server.

If you've already set up an SSH key to interact with GitHub, you're probably familiar with ssh-agent. 
It's a program that runs in the background and keeps your key loaded into memory, so that you don't need to enter your passphrase every time you need to use the key. 
The nifty thing is, you can choose to let servers access your local ssh-agent as if they were already running on the server. 

This is sort of like asking a friend to enter their password so that you can use their computer.
Check out Steve Friedl's Tech Tips guide for a more detailed explanation of SSH agent forwarding.
 Setting up SSH agent forwarding
Ensure that your own SSH key is set up and working. 
You can use our guide on generating SSH keys if you've not done this yet.
You can test that your local key works by entering ssh -T git@github.com in the terminal:
$ ssh -T git@github.com
# Attempt to SSH in to github
> Hi USERNAME! You've successfully authenticated, but GitHub does not provide
> shell access.
We're off to a great start. 

Let's set up SSH to allow agent forwarding to your server.
Using your favorite text editor, open up the file at ~/.ssh/config. 
If this file doesn't exist, you can create it by entering touch ~/.ssh/config in the terminal.
Enter the following text into the file, replacing example.com with your server's domain name or IP:
Host example.com
 ForwardAgent yes
Warning: You may be tempted to use a wildcard like Host * to just apply this setting to all SSH connections. 
That's not really a good idea, as you'd be sharing your local SSH keys with every server you SSH into. 
They won't have direct access to the keys, but they will be able to use them as you while the connection is established. 
You should only add servers you trust and that you intend to use with agent forwarding.
 Testing SSH agent forwarding
To test that agent forwarding is working with your server, you can SSH into your server and run ssh -T git@github.com once more. 
If all is well, you'll get back the same prompt as you did locally.
If you're unsure if your local key is being used, you can also inspect the SSH_AUTH_SOCK variable on your server:
$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> /tmp/ssh-4hNGMk8AZX/agent.79453
If the variable is not set, it means that agent forwarding is not working:
$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> [No output]
$ ssh -T git@github.com
# Try to SSH to github
> Permission denied (publickey).
 Troubleshooting SSH agent forwarding
Here are some things to look out for when troubleshooting SSH agent forwarding.
  You must be using an SSH URL to check out code
SSH forwarding only works with SSH URLs, not HTTP(s) URLs. 
Check the .git/config file on your server and ensure the URL is an SSH-style URL like below:
[remote "origin"]
 url = git@github.com:YOUR_ACCOUNT/YOUR_PROJECT.git
 fetch = +refs/heads/*:refs/remotes/origin/*
  Your SSH keys must work locally
Before you can make your keys work through agent forwarding, they must work locally first. 
Our guide on generating SSH keys can help you set up your SSH keys locally.

  Your system must allow SSH agent forwarding
Sometimes, system configurations disallow SSH agent forwarding. 
You can check if a system configuration file is being used by entering the following command in the terminal:
$ ssh -v URL
# Connect to the specified URL with verbose debug output
> OpenSSH_8.1p1, LibreSSL 2.7.3
> debug1: Reading configuration data /Users/YOU/.ssh/config
> debug1: Applying options for example.com
> debug1: Reading configuration data /etc/ssh_config
> debug1: Applying options for *
$ exit
# Returns to your local command prompt
In the example above, the file ~/.ssh/config is loaded first, then /etc/ssh_config is read. 
We can inspect that file to see if it's overriding our options by running the following commands:
$ cat /etc/ssh_config
# Print out the /etc/ssh_config file
> Host *
>   SendEnv LANG LC_*
>   ForwardAgent no
In this example, our /etc/ssh_config file specifically says ForwardAgent no, which is a way to block agent forwarding. 
Deleting this line from the file should get agent forwarding working once more.
  Your server must allow SSH agent forwarding on inbound connections
Agent forwarding may also be blocked on your server. 
You can check that agent forwarding is permitted by SSHing into the server and running sshd_config. 
The output from this command should indicate that AllowAgentForwarding is set.
  Your local ssh-agent must be running
On most computers, the operating system automatically launches ssh-agent for you. 
On Windows, however, you need to do this manually. 
We have a guide on how to start ssh-agent whenever you open Git Bash.
To verify that ssh-agent is running on your computer, type the following command in the terminal:
$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> /tmp/launch-kNSlgU/Listeners
  Your key must be available to ssh-agent
You can check that your key is visible to ssh-agent by running the following command:
ssh-add -L
If the command says that no identity is available, you'll need to add your key:
$ ssh-add YOUR-KEY
On macOS, ssh-agent will "forget" this key, once it gets restarted during reboots. 
But you can import your SSH keys into Keychain using this command:
$ ssh-add --apple-use-keychain YOUR-KEY
For MacOS versions prior to Monterey (12.0), use -K instead of --apple-use-keychain. 
Managing deploy keys
Learn different ways to manage SSH keys on your servers when you automate deployment scripts and which way is best for you.
You can manage SSH keys on your servers when automating deployment scripts using SSH agent forwarding, HTTPS with OAuth tokens, deploy keys, or machine users.
 SSH agent forwarding
In many cases, especially in the beginning of a project, SSH agent forwarding is the quickest and simplest method to use. 
Agent forwarding uses the same SSH keys that your local development computer uses.
  Pros of SSH agent forwarding

You do not have to generate or keep track of any new keys.
There is no key management; users have the same permissions on the server that they do locally.
No keys are stored on the server, so in case the server is compromised, you don't need to hunt down and remove the compromised keys.

  Cons of SSH agent forwarding

Users must SSH in to deploy; automated deploy processes can't be used.
SSH agent forwarding can be troublesome to run for Windows users.

  Set up SSH agent forwarding
Turn on agent forwarding locally. 
See our guide on SSH agent forwarding for more information.
Set your deploy scripts to use agent forwarding. 
For example, on a bash script, enabling agent forwarding would look something like this:
ssh -A serverA 'bash -s' < deploy.sh
 HTTPS cloning with OAuth tokens
If you don't want to use SSH keys, you can use HTTPS with OAuth tokens.
  Pros of HTTPS cloning with OAuth tokens

Anyone with access to the server can deploy the repository.
Users don't have to change their local SSH settings.
Multiple tokens (one for each user) are not needed; one token per server is enough.
A token can be revoked at any time, turning it essentially into a one-use password.

  Cons of HTTPS cloning with OAuth tokens

You must make sure that you configure your token with the correct access scopes.
Tokens are essentially passwords, and must be protected the same way.

  Set up HTTPS cloning with OAuth tokens
See our guide on creating a personal access token.
 Deploy keys
You can launch projects from a repository on GitHub.com to your server by using a deploy key, which is an SSH key that grants access to a single repository. 
GitHub attaches the public part of the key directly to your repository instead of a personal account, and the private part of the key remains on your server. 
Deploy keys with write access can perform the same actions as an organization member with admin access, or a collaborator on a personal repository. 
  Pros of deploy keys

Anyone with access to the repository and server has the ability to deploy the project.
Users don't have to change their local SSH settings.
Deploy keys are read-only by default, but you can give them write access when adding them to a repository.

  Cons of deploy keys

Deploy keys only grant access to a single repository. 
More complex projects may have many repositories to pull to the same server.
Deploy keys are usually not protected by a passphrase, making the key easily accessible if the server is compromised.

  Set up deploy keys
Run the ssh-keygen procedure on your server, and remember where you save the generated public and private rsa key pair.
On GitHub.com, navigate to the main page of the repository.
Under your repository name, click  Settings. 
If you cannot see the "Settings" tab, select the  dropdown menu, then click Settings.

In the sidebar, click Deploy Keys.
Click Add deploy key.
In the "Title" field, provide a title.
In the "Key" field, paste your public key.
Select Allow write access if you want this key to have write access to the repository. 
A deploy key with write access lets a deployment push to the repository.
Click Add key.
  Using multiple repositories on one server
If you use multiple repositories on one server, you will need to generate a dedicated key pair for each one. 
You can't reuse a deploy key for multiple repositories.
In the server's SSH configuration file (usually ~/.ssh/config), add an alias entry for each repository. 
For example:
Host github.com-repo-0
       Hostname github.com
       IdentityFile=/home/user/.ssh/repo-0_deploy_key
Host github.com-repo-1
       Hostname github.com
       IdentityFile=/home/user/.ssh/repo-1_deploy_key

Host github.com-repo-0 - The repository's alias.
Hostname github.com - Configures the hostname to use with the alias.
IdentityFile=/home/user/.ssh/repo-0_deploy_key - Assigns a private key to the alias.

You can then use the hostname's alias to interact with the repository using SSH, which will use the unique deploy key assigned to that alias. 
For example:
$ git clone git@github.com-repo-1:OWNER/repo-1.git
 GitHub App installation access tokens
If your server needs to access repositories across one or more organizations, you can use a GitHub App to define the access you need, and then generate tightly-scoped, installation access tokens from that GitHub App. 
The installation access tokens can be scoped to single or multiple repositories, and can have fine-grained permissions. 
For example, you can generate a token with read-only access to a repository's contents.
Since GitHub Apps are a first class actor on  GitHub, the installation access tokens are decoupled from any GitHub user, which makes them comparable to "service tokens". 
Additionally, installation access tokens have dedicated rate limits that scale with the size of the organizations that they act upon. 
  Pros of installation access tokens

Tightly-scoped tokens with well-defined permission sets and expiration times (1 hour, or less if revoked manually using the API).
Dedicated rate limits that grow with your organization.
Decoupled from GitHub user identities, so they do not consume any licensed seats.
Never granted a password, so cannot be directly signed in to.

  Cons of installation access tokens

Additional setup is needed to create the GitHub App.
Installation access tokens expire after 1 hour, and so need to be re-generated, typically on-demand using code.

  Set up installation access tokens
Determine if your GitHub App should be public or private. 
If your GitHub App will only act on repositories within your organization, you likely want it private.
Determine the permissions your GitHub App requires, such as read-only access to repository contents.
Create your GitHub App via your organization's settings page. 
Note your GitHub App id.
Generate and download your GitHub App's private key, and store this safely. 
Install your GitHub App on the repositories it needs to act upon, optionally you may install the GitHub App on all repositories in your organization.
Identify the installation_id that represents the connection between your GitHub App and the organization repositories it can access. 
Each GitHub App and organization pair have at most a single installation_id. 
You can identify this installation_id via Get an organization installation for the authenticated app. 
This requires authenticating as a GitHub App using a JWT, for more information see Authenticating as a GitHub App.
Generate an installation access token using the corresponding REST API endpoint, Create an installation access token for an app. 
This requires authenticating as a GitHub App using a JWT, for more information see Authenticating as a GitHub App, and Authenticating as an installation.
Use this installation access token to interact with your repositories, either via the REST or GraphQL APIs, or via a Git client.
 Machine users
If your server needs to access multiple repositories, you can create a new account on GitHub.com and attach an SSH key that will be used exclusively for automation. 
Since this account on GitHub.com won't be used by a human, it's called a machine user. 
You can add the machine user as a collaborator on a personal repository (granting read and write access), as an outside collaborator on an organization repository (granting read, write, or admin access), or to a team with access to the repositories it needs to automate (granting the permissions of the team).
Tip: Our terms of service state:

Accounts registered by "bots" or other automated methods are not permitted.

This means that you cannot automate the creation of accounts. 
But if you want to create a single machine user for automating tasks such as deploy scripts in your project or organization, that is totally cool.
  Pros of machine users

Anyone with access to the repository and server has the ability to deploy the project.
No (human) users need to change their local SSH settings.
Multiple keys are not needed; one per server is adequate.

  Cons of machine users

Only organizations can restrict machine users to read-only access. 
Personal repositories always grant collaborators read/write access.
Machine user keys, like deploy keys, are usually not protected by a passphrase.

  Set up machine users
Run the ssh-keygen procedure on your server and attach the public key to the machine user account.
Give the machine user account access to the repositories you want to automate. 
You can do this by adding the account as a collaborator, as an outside collaborator, or to a team in an organization.
Checking for existing SSH keys
Before you generate an SSH key, you can check to see if you have any existing SSH keys.
 About SSH keys
You can use SSH to perform Git operations in repositories on GitHub.com. 
If you have an existing SSH key, you can use the key to authenticate Git operations over SSH.
 Checking for existing SSH keys
Before you generate a new SSH key, you should check your local machine for existing keys.
Note: GitHub improved security by dropping older, insecure key types on March 15, 2022.
As of that date, DSA keys (ssh-dss) are no longer supported. 
You cannot add new DSA keys to your personal account on GitHub.com.
RSA keys (ssh-rsa) with a valid_after before November 2, 2021 may continue to use any signature algorithm. 
RSA keys generated after that date must use a SHA-2 signature algorithm. 
Some older clients may need to be upgraded in order to use SHA-2 signatures.
Open TerminalTerminalGit Bash.
Enter ls -al ~/.ssh to see if existing SSH keys are present.
$ ls -al ~/.ssh
# Lists the files in your .ssh directory, if they exist
Check the directory listing to see if you already have a public SSH key. 
By default, the filenames of supported public keys for GitHub are one of the following.

id_rsa.pub
id_ecdsa.pub
id_ed25519.pub

Tip: If you receive an error that ~/.ssh doesn't exist, you do not have an existing SSH key pair in the default location. 
You can create a new SSH key pair in the next step.
Either generate a new SSH key or upload an existing key.

If you don't have a supported public and private key pair, or don't wish to use any that are available, generate a new SSH key.
If you see an existing public and private key pair listed (for example, id_rsa.pub and id_rsa) that you would like to use to connect to GitHub, you can add the key to the ssh-agent.
For more information about generation of a new SSH key or addition of an existing key to the ssh-agent, see "Generating a new SSH key and adding it to the ssh-agent."
Generating a new SSH key and adding it to the ssh-agent
After you've checked for existing SSH keys, you can generate a new SSH key to use for authentication, then add it to the ssh-agent.
 About SSH key passphrases
You can access and write data in repositories on GitHub.com using SSH (Secure Shell Protocol). 
When you connect via SSH, you authenticate using a private key file on your local machine. 
When you generate an SSH key, you can add a passphrase to further secure the key. 
Whenever you use the key, you must enter the passphrase. 
If your key has a passphrase and you don't want to enter the passphrase every time you use the key, you can add your key to the SSH agent. 
The SSH agent manages your SSH keys and remembers your passphrase.
If you don't already have an SSH key, you must generate a new SSH key to use for authentication. 
If you're unsure whether you already have an SSH key, you can check for existing keys. 
If you want to use a hardware security key to authenticate to GitHub, you must generate a new SSH key for your hardware security key. 
You must connect your hardware security key to your computer when you authenticate with the key pair. 
 Generating a new SSH key
You can generate a new SSH key on your local machine. 
After you generate the key, you can add the key to your account on GitHub.com to enable authentication for Git operations over SSH.
Note: GitHub improved security by dropping older, insecure key types on March 15, 2022.
As of that date, DSA keys (ssh-dss) are no longer supported. 
You cannot add new DSA keys to your personal account on GitHub.com.
RSA keys (ssh-rsa) with a valid_after before November 2, 2021 may continue to use any signature algorithm. 
RSA keys generated after that date must use a SHA-2 signature algorithm. 
Some older clients may need to be upgraded in order to use SHA-2 signatures.
Open TerminalTerminalGit Bash.
Paste the text below, substituting in your GitHub email address.
  $ ssh-keygen -t ed25519 -C "your_email@example.com"
  
  Note: If you are using a legacy system that doesn't support the Ed25519 algorithm, use:
  $ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
  
  This creates a new SSH key, using the provided email as a label.
  > Generating public/private ALGORITHM key pair.
When you're prompted to "Enter a file in which to save the key", you can press Enter to accept the default file location. 
Please note that if you created SSH keys previously, ssh-keygen may ask you to rewrite another key, in which case we recommend creating a custom-named SSH key. 
To do so, type the default file location and replace id_ssh_keyname with your custom key name.
  
  > Enter a file in which to save the key (/Users/YOU/.ssh/id_ALGORITHM: [Press enter]
  
  
  > Enter a file in which to save the key (/c/Users/YOU/.ssh/id_ALGORITHM):[Press enter]
  
  
  > Enter a file in which to save the key (/home/YOU/.ssh/ALGORITHM):[Press enter]
  
At the prompt, type a secure passphrase. 
> Enter passphrase (empty for no passphrase): [Type a passphrase]
> Enter same passphrase again: [Type passphrase again]
 Adding your SSH key to the ssh-agent
Before adding a new SSH key to the ssh-agent to manage your keys, you should have checked for existing SSH keys and generated a new SSH key. 
When adding your SSH key to the agent, use the default macOS ssh-add command, and not an application installed by macports, homebrew, or some other external source.
Start the ssh-agent in the background. 
$ eval "$(ssh-agent -s)"
> Agent pid 59566
Depending on your environment, you may need to use a different command. 
For example, you may need to use root access by running sudo -s -H before starting the ssh-agent, or you may need to use exec ssh-agent bash or exec ssh-agent zsh to run the ssh-agent.
If you're using macOS Sierra 10.12.2 or later, you will need to modify your ~/.ssh/config file to automatically load keys into the ssh-agent and store passphrases in your keychain.

First, check to see if your ~/.ssh/config file exists in the default location.
$ open ~/.ssh/config
> The file /Users/YOU/.ssh/config does not exist.
If the file doesn't exist, create the file.
$ touch ~/.ssh/config
Open your ~/.ssh/config file, then modify the file to contain the following lines. 
If your SSH key file has a different name or path than the example code, modify the filename or path to match your current setup.
Host github.com
 AddKeysToAgent yes
 UseKeychain yes
 IdentityFile ~/.ssh/id_ed25519
Notes:

If you chose not to add a passphrase to your key, you should omit the UseKeychain line.
If you see a Bad configuration option: usekeychain error, add an additional line to the configuration's' Host *.github.com section.
Host github.com
 IgnoreUnknown UseKeychain


Add your SSH private key to the ssh-agent and store your passphrase in the keychain. 
If you created your key with a different name, or if you are adding an existing key that has a different name, replace id_ed25519 in the command with the name of your private key file.
$ ssh-add --apple-use-keychain ~/.ssh/id_ed25519
Note: The --apple-use-keychain option stores the passphrase in your keychain for you when you add an SSH key to the ssh-agent. 
If you chose not to add a passphrase to your key, run the command without the --apple-use-keychain option.
The --apple-use-keychain option is in Apple's standard version of ssh-add. 
In MacOS versions prior to Monterey (12.0), the --apple-use-keychain and --apple-load-keychain flags used the syntax -K and -A, respectively.
If you don't have Apple's standard version of ssh-add installed, you may receive an error. 

Add the SSH key to your account on GitHub. 
If you have GitHub Desktop installed, you can use it to clone repositories and not deal with SSH keys.
Ensure the ssh-agent is running. 
You can use the "Auto-launching the ssh-agent" instructions in "Working with SSH key passphrases", or start it manually:
# start the ssh-agent in the background
$ eval "$(ssh-agent -s)"
> Agent pid 59566
Add your SSH private key to the ssh-agent. 
If you created your key with a different name, or if you are adding an existing key that has a different name, replace id_ed25519 in the command with the name of your private key file.
$ ssh-add ~/.ssh/id_ed25519
Add the SSH key to your account on GitHub. 
Start the ssh-agent in the background. 
$ eval "$(ssh-agent -s)"
> Agent pid 59566
Depending on your environment, you may need to use a different command. 
For example, you may need to use root access by running sudo -s -H before starting the ssh-agent, or you may need to use exec ssh-agent bash or exec ssh-agent zsh to run the ssh-agent.
Add your SSH private key to the ssh-agent. 
If you created your key with a different name, or if you are adding an existing key that has a different name, replace id_ed25519 in the command with the name of your private key file.
$ ssh-add ~/.ssh/id_ed25519
Add the SSH key to your account on GitHub. 
 Generating a new SSH key for a hardware security key
If you are using macOS or Linux, you may need to update your SSH client or install a new SSH client prior to generating a new SSH key. 
Insert your hardware security key into your computer.
Open TerminalTerminalGit Bash.
Paste the text below, substituting in the email address for your account on GitHub.
$ ssh-keygen -t ed25519-sk -C "YOUR_EMAIL"
Note: If the command fails and you receive the error invalid format or feature not supported, you may be using a hardware security key that does not support the Ed25519 algorithm. 
Enter the following command instead.
$ ssh-keygen -t ecdsa-sk -C "your_email@example.com"
When you are prompted, touch the button on your hardware security key.
When you are prompted to "Enter a file in which to save the key," press Enter to accept the default file location.
> Enter a file in which to save the key (/Users/YOU/.ssh/id_ed25519_sk): [Press enter]
> Enter a file in which to save the key (/c/Users/YOU/.ssh/id_ed25519_sk):[Press enter]
> Enter a file in which to save the key (/home/YOU/.ssh/id_ed25519_sk):[Press enter]
When you are prompted to type a passphrase, press Enter.
> Enter passphrase (empty for no passphrase): [Type a passphrase]
> Enter same passphrase again: [Type passphrase again]
Add the SSH key to your account on GitHub. 
Adding a new SSH key to your GitHub account
To configure your account on GitHub.com to use your new (or existing) SSH key, you'll also need to add the key to your account.
 About addition of SSH keys to your account
You can access and write data in repositories on GitHub.com using SSH (Secure Shell Protocol). 
When you connect via SSH, you authenticate using a private key file on your local machine. 
You can also use SSH to sign commits and tags. 
For more information about commit signing, see "About commit signature verification."
After you generate an SSH key pair, you must add the public key to GitHub.com to enable SSH access for your account.
 Prerequisites
Before adding a new SSH key to your account on GitHub.com, complete the following steps.
Check for existing SSH keys. 
Generate a new SSH key and add it to your machine's SSH agent. 
 Adding a new SSH key to your account
After adding a new SSH authentication key to your account on GitHub.com, you can reconfigure any local repositories to use SSH. 
Note: GitHub improved security by dropping older, insecure key types on March 15, 2022.
As of that date, DSA keys (ssh-dss) are no longer supported. 
You cannot add new DSA keys to your personal account on GitHub.com.
RSA keys (ssh-rsa) with a valid_after before November 2, 2021 may continue to use any signature algorithm. 
RSA keys generated after that date must use a SHA-2 signature algorithm. 
Some older clients may need to be upgraded in order to use SHA-2 signatures.
Copy the SSH public key to your clipboard.
 If your SSH public key file has a different name than the example code, modify the filename to match your current setup. 
When copying your key, don't add any newlines or whitespace.
 $ pbcopy < ~/.ssh/id_ed25519.pub
 # Copies the contents of the id_ed25519.pub file to your clipboard
 
 Tip: If pbcopy isn't working, you can locate the hidden .ssh folder, open the file in your favorite text editor, and copy it to your clipboard.
 
 $ clip < ~/.ssh/id_ed25519.pub
 # Copies the contents of the id_ed25519.pub file to your clipboard
 
 Tip: With Windows Subsystem for Linux (WSL), you can use clip.exe. 
Otherwise if clip isn't working, you can locate the hidden .ssh folder, open the file in your favorite text editor, and copy it to your clipboard.
 
 $ cat ~/.ssh/id_ed25519.pub
 # Then select and copy the contents of the id_ed25519.pub file
 # displayed in the terminal to your clipboard
 
 Tip: Alternatively, you can locate the hidden .ssh folder, open the file in your favorite text editor, and copy it to your clipboard.
 
In the upper-right corner of any page, click your profile photo, then click Settings. 

In the "Access" section of the sidebar, click  SSH and GPG keys.
Click New SSH key or Add SSH key.

In the "Title" field, add a descriptive label for the new key. 
For example, if you're using a personal laptop, you might call this key "Personal laptop".
Select the type of key, either authentication or signing. 
For more information about commit signing, see "About commit signature verification."
Paste your public key into the "Key" field.

Click Add SSH key.

If prompted, confirm access to your account on GitHub. 
To learn more about GitHub CLI, see "About GitHub CLI."
Before you can use the GitHub CLI to add an SSH key to your account, you must authenticate to the GitHub CLI. 
At present, you can only use GitHub CLI to add SSH authentication keys, you cannot add SSH signing keys.
To add an SSH authentication key to your GitHub account, use the ssh-key add subcommand, specifying your public key.
gh ssh-key add KEY-FILE
To include a title for the new key, use the -t or --title flag.
gh ssh-key add KEY-FILE --title "personal laptop"
If you generated your SSH key by following the instructions in "Generating a new SSH key and adding it to the ssh-agent", you can add the key to your account with this command.
gh ssh-key add ~/.ssh/id_ed25519.pub
Testing your SSH connection
After you've set up your SSH key and added it to your account on GitHub.com, you can test your connection.
Before testing your SSH connection, you should have:
Checked for existing SSH keys
Generated a new SSH key
Added a new SSH key to your GitHub account
When you test your connection, you'll need to authenticate this action using your password, which is the SSH key passphrase you created earlier. 
For more information on working with SSH key passphrases, see "Working with SSH key passphrases."
Open TerminalTerminalGit Bash.
Enter the following:
$ ssh -T git@github.com
# Attempts to ssh to GitHub
You may see a warning like this:
> The authenticity of host 'github.com (IP ADDRESS)' can't be established.
> RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
> Are you sure you want to continue connecting (yes/no)?
Verify that the fingerprint in the message you see matches GitHub's public key fingerprint. 
If it does, then type yes:
> Hi USERNAME! You've successfully authenticated, but GitHub does not
> provide shell access.
You may see this error message:
...
Agent admitted failure to sign using the key.
debug1: No more authentication methods to try.
Permission denied (publickey).
This is a known problem with certain Linux distributions. 

Note: The remote command should exit with code 1.

Verify that the resulting message contains your username. 
If you receive a "permission denied" message, see "Error: Permission denied (publickey)."
Working with SSH key passphrases
In this article
About passphrases for SSH keys
You can secure your SSH keys and configure an authentication agent so that you won't have to reenter your passphrase every time you use your SSH keys.
 About passphrases for SSH keys
With SSH keys, if someone gains access to your computer, the attacker can gain access to every system that uses that key. 
To add an extra layer of security, you can add a passphrase to your SSH key. 
To avoid entering the passphrase every time you connect, you can securely save your passphrase in the SSH agent.
 Adding or changing a passphrase
You can change the passphrase for an existing private key without regenerating the keypair by typing the following command:
$ ssh-keygen -p -f ~/.ssh/id_ed25519
> Enter old passphrase: [Type old passphrase]
> Key has comment 'your_email@example.com'
> Enter new passphrase (empty for no passphrase): [Type new passphrase]
> Enter same passphrase again: [Repeat the new passphrase]
> Your identification has been saved with the new passphrase.
If your key already has a passphrase, you will be prompted to enter it before you can change to a new passphrase.
 Auto-launching ssh-agent on Git for Windows
You can run ssh-agent automatically when you open bash or Git shell. 
Copy the following lines and paste them into your ~/.profile or ~/.bashrc file in Git shell:
env=~/.ssh/agent.env
agent_load_env () { test -f "$env" && . 
"$env" >| /dev/null ; }
agent_start () {
   (umask 077; ssh-agent >| "$env")
   . 
"$env" >| /dev/null ; }
agent_load_env
# agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2=agent not running
agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?)
if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then
   agent_start
   ssh-add
elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then
   ssh-add
fi
unset env
If your private key is not stored in one of the default locations (like ~/.ssh/id_rsa), you'll need to tell your SSH authentication agent where to find it. 
To add your key to ssh-agent, type ssh-add ~/path/to/my_key. 
Tip: If you want ssh-agent to forget your key after some time, you can configure it to do so by running ssh-add -t <seconds>.
Now, when you first run Git Bash, you are prompted for your passphrase:
> Initializing new SSH agent...
> succeeded
> Enter passphrase for /c/Users/YOU/.ssh/id_rsa:
> Identity added: /c/Users/YOU/.ssh/id_rsa (/c/Users/YOU/.ssh/id_rsa)
> Welcome to Git (version 1.6.0.2-preview20080923)
>
> Run 'git help git' to display the help index.
> Run 'git help ' to display help for specific commands.
The ssh-agent process will continue to run until you log out, shut down your computer, or kill the process.
 Saving your passphrase in the keychain
On Mac OS X Leopard through OS X El Capitan, these default private key files are handled automatically:

.ssh/id_rsa
.ssh/identity

The first time you use your key, you will be prompted to enter your passphrase. 
If you choose to save the passphrase with your keychain, you won't have to enter it again.
Otherwise, you can store your passphrase in the keychain when you add your key to the ssh-agent.