GitHub Authentication: SSH Keys vs. PATs – Choosing the Right Secure Option

GitHub Authentication: SSH Keys vs. PATs – Choosing the Right Secure Option

🐙Comparing SSH Keys and PAT for Better GitHub Security

This blog post is intended for developers familiar with GitHub who want to explore secure authentication methods beyond passwords.

📜Introduction

"**If you're a developer, sysadmin, cloud engineer, or in a related role and have worked with GitHub, imagine a world where you can ditch passwords for GitHub!" This dream becomes reality with SSH keys and Personal Access Tokens (PATs). These secure methods not only streamline your workflow but also enhance security.

GitHub's ecosystem includes features like GitHub Actions, GitHub Pages, GitHub Packages, large community, extensive documentation, integrations to various tools etc. It's awesome but making sure that it is secure is important. We will look into two popular authentication mechanisms i.e. SSH keys and Personal Access Tokens (PATs). This will be easy to understand, and we will dig into some helpful commands we can run on the terminal!

🗝️Super Secure SSH Keys:

Ever wish you could have a magic key to your GitHub goodies, not another password? Enter SSH keys!

SSH (Secure Shell) keys are a pair of cryptographic keys used to securely connect to remote systems. Instead of providing your password, you just supply the private key.

  • If you work with GitHub repositories on a regular basis and want to avoid password hassles, SSH is a great alternative. It can even work if you are running everything in an automated way or through scripts.

🔑Customizable Personal Access Tokens (PATs):

Think of a PAT as a personal access token for GitHub. Instead of using your password, you can use this token to perform read and write actions via HTTPS. Even better?! You get to decide what actions this token can perform! PATs are great if you can't or don't want to use SSH keys. They also are useful if you want to integrate with other services through GitHub.

  • PATs offer an extra layer of security by allowing you to grant fine-grained permissions.

    For example, you can create a PAT specifically for read-only access to a public repository, or a PAT for pushing code to a private repository but limit its ability to delete branches. This control is particularly useful for integrations with other services or for providing access to team members with specific needs.

  • It's important to note that HTTPS with strong, unique passwords can also be secure, especially for infrequent actions or less sensitive repositories. However, SSH keys offer a more convenient and generally more secure option for frequent Git operations, automated workflows, or when password security is a concern.

💻Logging in with GitHub CLI and Creating a Repository

First, we authenticate the GitHub CLI with our account, confirm a few aspects like the preferred protocol (HTTPS) and authentication method (web browser), and after a successful login, the CLI configures the Git protocol and displays our username.

After logging in, we use the gh repo create command with the repository name (ssh_pat_testing) and the --public flag to create a public repository, and the terminal confirms the creation with a message and a link to the new repository on GitHub.

📂Clone Repository Using SSH

Let's first clone our ssh_pat_testing repo to our local Linux server.

debian@alpha2:~$ git clone  https://github.com/guptajeet/ssh_pat_testing
Cloning into 'ssh_pat_testing'...
warning: You appear to have cloned an empty repository.
debian@alpha2:~$ ls
ssh_pat_testing  test_project

📤Push Changes Using SSH

In this section, we'll set up a local Git repository and push it to GitHub using SSH key authentication.

💡
Noticeably, we weren't prompted for a password during this process. This is because SSH key authentication is configured, which provides a more secure and convenient way to connect to remote servers.
debian@alpha2:~$ cd ssh_pat_testing

debian@alpha2:~/ssh_pat_testing$ echo '# this is test readme file' > README.md

debian@alpha2:~/ssh_pat_testing$ ls
README.md

debian@alpha2:~/ssh_pat_testing$ git init
Reinitialized existing Git repository in /home/debian/ssh_pat_testing/.git/
debian@alpha2:~/ssh_pat_testing$ git add .

debian@alpha2:~/ssh_pat_testing$ git commit -m "commited to add README.md file"
[main (root-commit) 2ea3a7b] commited to add README.md file
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

debian@alpha2:~/ssh_pat_testing$ git remote add ssh_pat_testing git@github.com:guptajeet/ssh_pat_testing.git

debian@alpha2:~/ssh_pat_testing$ git remote -v
ssh_pat_testing git@github.com:guptajeet/ssh_pat_testing.git (fetch)
ssh_pat_testing git@github.com:guptajeet/ssh_pat_testing.git (push)

debian@alpha2:~/ssh_pat_testing$ git push ssh_pat_testing main
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 255 bytes | 127.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:guptajeet/ssh_pat_testing.git
 * [new branch]      main -> main
Steps -
  • Change directory: cd ssh_pat_testing

  • Create README: echo '# this is test readme file' > README.md

  • Initialize Git: git init

  • Stage changes: git add .

  • Commit changes: git commit -m

  • Add remote (SSH): git remote add ssh_pat_testing git@github.com:guptajeet/ssh_pat_testing.git

  • Verify remote: git remote -v

  • Push changes: git push ssh_pat_testing main

🌐Push Changes Using PAT

In this section we are going to push file to repo using PAT.

💡
When using HTTPS to push to a remote repository, We'll be prompted for your GitHub username and password. This is because HTTPS authentication relies on these credentials to verify identity. SSH key authentication, covered earlier, offers a more secure alternative that avoids needing to enter your password repeatedly.
debian@alpha2:~/ssh_pat_testing$ touch app.py
debian@alpha2:~/ssh_pat_testing$ vi app.py

debian@alpha2:~/ssh_pat_testing$ git init
Reinitialized existing Git repository in /home/debian/ssh_pat_testing/.git/

debian@alpha2:~/ssh_pat_testing$ git add .

debian@alpha2:~/ssh_pat_testing$ git commit -m "coomitted to add app.py file"
[main bb1fe90] coomitted to add app.py file

debian@alpha2:~/ssh_pat_testing$ git remote add ssh_pat_testing1 https://github.com/guptajeet/ssh_pat_testing.git

debian@alpha2:~/ssh_pat_testing$ git remote -v
ssh_pat_testing git@github.com:guptajeet/ssh_pat_testing.git (fetch)
ssh_pat_testing git@github.com:guptajeet/ssh_pat_testing.git (push)
ssh_pat_testing1        https://github.com/guptajeet/ssh_pat_testing.git (fetch)
ssh_pat_testing1        https://github.com/guptajeet/ssh_pat_testing.git (push)

debian@alpha2:~/ssh_pat_testing$ git push ssh_pat_testing1 main
Username for 'https://github.com': guptajeet
Password for 'https://guptajeet@github.com':
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 420 bytes | 420.00 KiB/s, done.
Steps -
  • Create Sample Python file: app.py

  • Edit file: Write Python code in app.py

  • Add and commit:

    • Stage changes git add .

    • Commit with a message git commit -m

  • Add remote (HTTPS): ssh_pat_testing1 for https://github.com/guptajeet/ssh_pat_testing.git

  • Verify remotes: Check configured remotes git remote -v

  • Push changes: Push to main branch, enter credentials when prompted git push

📚Summary

It depends on what you want to achieve, but these are the differences:

  1. SSH keys: If you don't want to use a password (or remove it from the equation), and want a secure connection for frequent git operations and/or automated processes.

  2. Personal Access Tokens: Useful for environments where HTTPS is preferred, or SSH connections are not practical. PATs offer the flexibility to provide varied levels of permissions.

Both SSH keys and PATs offer secure repository interactions with GitHub. Choose the method that best suits your needs: SSH keys for frequent and automated operations without passwords, and PATs for flexibility with varied permissions.