Setting up SSH keys are often used for services like GitHub, GitLab, Netlify, AWS, remote SSH servers, and other cloud services.

While it’s possible to connect to most SSH servers/services with just a username and password, this gets old fast if you’re doing this 50+ times a day.

Also, since usernames and passwords are relatively simple to bypass, most services listed above require password-less authentication using cryptographic public-key (aka asymmetric key) secured logins, which is what I’ll be showing you how to set up in this blog post.

Read more in detail

• Asymmetric Encryption explained with the help of chocolate boxes. | Hacker Noon
• Configure SSH key based secure authentication
• GitLab and SSH keys | GitLab
• Git: git@gitlab.com: Permission denied (publickey) with VSC 😭 - Questions & Answers - GitLab Forum

At a high-level we will be doing the following

• Generating a secure password for your SSH keys
• Generating public and private keys using the secure password
• Transferring the public key from your local machine to the remote services you’ll be using (eg. GitHub or an SSH server you want to connect to)
• Setting up your local SSH configuration file
• Adding keys to your OS keychain and update your shell profile
• Verifying that it all works correctly

Let’s get cracking.

Generate a secure password

Generating secure passwords is a huge topic on its own, so I’m not going to go into that level of detail here. If you’re already an expert at generating secure passwords, then feel free to skip this step.

If you’re planning on using password123, mydawgrulez, your birthday, phone number, or some other easily guessable/crackable passphrase…don’t. There’s a better way.

I’ve found the easiest way to generate a secure password that works on most systems is to take a “random” and “unique” string (like the current timestamp), plus some additional random text of your choosing, then pass the entire string through a hashing function like so:

    date | sed 's/$/ [some-other-random-text-here]/' | md5

The above timestamp or date is not “random”, but since the output of date changes every second appended with the random text, it’s going to be secure enough for most purposes.

You’ll get a string similar to this one as an output:

    33d2623533300a62e08866c7b49c22bc

This is your new password that you’ll use to generate your keys in the next step.

TIP: You can also use the LastPass Password Generator UI to generate passwords as well. I recommend a password of at least 32 characters using all available characters.

Also, if you aren’t using password manager/storage utility here’s a FOSS way to store your sensitive information.

Generate public and private keys

Next, we’ll generate new SSH keys with the following command:

    ssh-keygen -t ed25519 -C "<comment>"

ED25519 is a new cryptographic standard, which improves upon previous standards like RSA, and is suggested for new keys and systems that support it.

It’s standard practice to use your email address for the <comment> string to help you label/identify your keys later on, but it can be whatever text you want.

Note: DO NOT ENTER YOUR PASSWORD HERE. This comment will show up in plaintext in your public key file.

Next, you’ll be prompted for a file path to save your keys. Hitting <enter> will save them in the default location specified.

Finally, enter in the password hash you created in the last step to generate your keys.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/Users/username/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/username/.ssh/id_ed25519.
Your public key has been saved in /Users/username/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:J572JSU087Q6oGTmEP+2cVN2qivzSpY/xNnkRNzW9rM <comment>
The key’s randomart image is:
+—[ED25519 256]—+
|           . . . |
|            o o o|
|    .     +… ..|
|     o   . =o. ..|
|    . = S.o** . o|
|     * + *+*oo E |
|      o @.* o    |
|       =o*.*     |
|        o=*o     |
+——[SHA256]——+

Check your local user SSH configuration folder to ensure that your new keys have been generated with ls:

    ls  ~/.ssh/

config				id_ed25519.pub			id_ed25519		known_hosts

The file ending in .pub is your PUBLIC KEY which you’ll share with the services that you wish to connect with.

The file without an extension is your PRIVATE KEY and should not be shared with anyone.

Transferring your public key

Copy your public key to your clipboard with the following command:

    pbcopy < ~/.ssh/id_ed25519.pub

Then paste it into the service that is requesting your public key. This is obviously different for each service so I’ll leave this part up to you.

If you’re logging into a remote SSH server and want to copy the keys over to the host, no need to copy and paste. The following command takes care of it for you:

    ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

Where user is your username and remote-host is the host your remote SSH server.

Setup your local SSH configuration file

On your local machine, edit your SSH ~/.ssh/config file with vi, nano, or your favorite text editor with the following example details.

Note: You can use a single key for multiple services as shown below, however this isn’t recommended in case your system is compromised. It’s generally more secure to generate new keys for each new service. Yes, it’s a pain in the ass do repeat this entire process each time you sign up for an account…but then again being pwned by a hacker is an even bigger pain.

Again, I leave this up to you.

Example ~/.ssh/config

# For all hosts
Host *
  UseKeychain yes
  AddKeysToAgent yes

# Example GitLab entry
Host gitlab.com
  HostName gitlab.com
  User git
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/id_ed25519

# Example GitHub entry
Host github.com
  HostName github.com
  User git
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/id_ed25519

You can also add in other SSH keys (other users) for the same service by creating a new entry changing the Host and the IdentityFile parameters like so:

# Example GitHub entry for second user
Host github.com-additionaluser
  HostName github.com
  User git
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/[users-private-key]

Or, add an entry for direct connection with an SSH server, where 1.2.3.4 is the host’s IP or domain name.

# Example entry for SSH server
Host 1.2.3.4-username
  HostName 1.2.3.4
  User username
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/[users-private-key]

Add keys to macOS keychain

An important last step that is often overlooked in most guides (especially if you are using macOS) is to add in the new keys to the Keychain:

    ssh-add -K ~/.ssh/[your-private-key]

IMPORTANT: Adding your SSH keys to your keychain in this way enables your system to use the keys for the duration of your session (until your next reboot). Again, this is an additional layer of security which some people may prefer in case their computer is stolen or hacked.

However, if you want to avoid typing the above command each time you log in to your computer, then see the next step.

Update shell profile

In order to automatically add your SSH keys to your keychain, edit your shells profile ~/.bash_profile with same command from above.

    ssh-add -K ~/.ssh/[your-private-key]

Now, each time you open a new shell, your SSH keys should be automatically added to the keychain.

Verify that it works

Finally, let’s make sure everything is working as it should. Close out the shell you were using, and reopen a fresh one if you haven’t already.

If you’re setting up SSH keys for GitHub or GitLab:

    git clone git@gitlab.com:gitlabusername/gitlabrepo.git

Where gitlabusername is your GitLab user name, and gitlabrepo is a Git repository you own.

Or, if you are logging into a remote SSH server:

    ssh user@remote-host

Boom. (⌐■_■)

You should now be able to successfully connect or log into your desired service without any passwords.

Enjoy!