DEV Community: JT Ziolo

Quickly and Easily Manage Multiple SSH and GPG Keys Across Git Repositories

JT Ziolo — Thu, 17 Oct 2024 01:58:58 +0000

Git relies on SSH and GPG to ensure secure and authenticated interactions with remote repositories. However, if you use multiple SSH and GPG identities and aren't careful while configuring Git, you can encounter specific issues when running Git commands. I've arrived at the following solution for these issues that I wanted to share since it may work well for others.

First, a disclaimer: this approach is not intended to replace full-featured identity management tools, and some customization may be required for more complex use cases (e.g., short-lived SSH or GPG keys), but I feel this can be helpful for some developers out there.

Understanding SSH and GPG in Git

SSH (Secure Shell) ensures secure communication between your local machine and remote Git repositories. When used with Git, it allows for encrypted data transfer and authentication, making it the preferred choice for interacting with popular hosting platforms like GitHub, GitLab, and Bitbucket ¹.

GPG (GNU Privacy Guard) can be used to digitally sign and verify Git commits. By signing their commits, developers prove their authorship over each commit and combat the threat of commit spoofing. Most version control providers support GPG signatures and offer mechanisms to verify signed commits ¹ ² ³.

The Pitfalls of Global SSH and GPG Settings

While global SSH and GPG settings can be convenient, relying solely on them can lead to complications, especially when managing multiple identities ¹:

SSH Key Confusion: When multiple SSH keys are configured globally, SSH may attempt to use the wrong key for authentication, resulting in failed login attempts. If authentication fails (e.g., because you mistyped the password), the agent cycles through each key to find a working one, which can be confusing and frustrating.
GPG Signing Errors: If you have multiple GPG keys, Git might use the incorrect key for signing, leading to verification failures when pushing commits.
Configuration Conflicts: Setting the wrong GPG or SSH key in your global Git configuration can cause signing failures across all repositories.

Checking the Git Identity with Bash

Before we continue, I'll assume you have already set up Git to require GPG-signed commits globally (this is controlled by the commit.gpgsign setting) ⁴.

Under normal circumstances, it can be challenging to determine which SSH key Git will use for fetch, pull, and push commands. To get around this, we'll force Git to use a specific SSH key file using the core.sshCommand setting. Here's an example of how you might change this setting from the command line:

git config core.sshCommand "ssh -i ~/.ssh/id_ed25519_johndoe_work -o IdentitiesOnly=yes"

Assuming that we have forced Git to use a specific SSH key file, we can quickly check which SSH and GPG keys Git will use with the following (barebones) Bash function. Feel free to edit it to produce neater output.

function git-check() {
    git config core.sshCommand
    git config user.name
    git config user.email
    git config user.signingkey
}

Add the function to your ~/.bashrc or ~/.bash_profile file, and source the file using source ~/.bashrc. You should now be able to navigate to a Git repo on your machine and run git-check to determine the identity that Git will use for the Git commands you run in that repo.

Security Considerations

The information we'll be working with is (in many cases) not as sensitive as you might think.

The filepath to the SSH file doesn't expose the key itself.
The user name and email settings contain public information for each git commit.
The GPG signing key fingerprint identifies the public key, and isn't sensitive.

We can prove that the GPG signing key used by Git isn't sensitive with a quick exercise. Go to GitHub and find a popular repo that has GPG-signed commits. If you click the "Verified" badge next to a commit, you'll see a message that includes the GPG key ID. This is the same value as the signing key that we will be using in our Git configuration.

Configuring Git for Specific SSH and GPG Keys

You can run the following Git configuration commands to configure the SSH and GPG keys used for each repo, just replace the key file path, signing key, and user settings to match your own:

git config core.sshCommand "ssh -i ~/.ssh/id_ed25519_johndoe_work -o IdentitiesOnly=yes"
git config user.signingkey "0123456789ABCDEF"
git config user.name "John Doe"
git config user.email "john.doe@example.com"

To get your GPG signing key, use gpg -K. In the output, look for the line starting with "sec" (which stands for secret key). The key ID will be displayed after the key type and size, typically in a format like rsa4096/0123456789ABCDEF. The key listed will likely be longer than the one shown. You only need the last 16 digits of the key but you can use more as long as the ending of the key is included.

Automating Local Repository Configuration

You probably don't want to look up your keys and run these commands manually on each repo that needs it. Luckily, it's pretty easy to use Bash to automate this process. Here's an example that can be used to setup a repo for either one of two identities, one for work projects and one for personal projects.

function git-setup-work() {
    git config core.sshCommand "ssh -i ~/.ssh/id_ed25519_johndoe_work -o IdentitiesOnly=yes"
    git config user.signingkey "0123456789ABCDEF"
    git config user.name "John Doe"
    git config user.email "john.doe@company.com"
}

function git-setup-personal() {
    git config core.sshCommand "ssh -i ~/.ssh/id_ed25519_johndoe_personal -o IdentitiesOnly=yes"
    git config user.signingkey "0123456789ABCDEF"
    git config user.name "JDNickName"
    git config user.email "jdnickname@gmail.com"
}

After defining these functions, source your Bash configuration file and run them to set up your repos as needed.

By following these practices, you can effectively manage multiple Git identities while avoiding common pitfalls associated with SSH and GPG configurations in Git.

Creating a Global .gitignore File as an Extra Line of Defense Against Bad Commits

JT Ziolo — Sat, 12 Oct 2024 01:12:34 +0000

Did you know that you can set up the equivalent of a global .gitignore file on your system? It's called an excludes file. You can set which file to use as your excludes file in your global git config under core.excludesFile. For example, to set the excludes file to the file named .gitexcludes in your home directory, use: git config --global core.excludesFile "~/.gitexcludes" (you can also edit your global .gitconfig file).

Note that this file is best used as an extra precaution. It should not take the place of setting up .gitignore files in your repos. Your excludes file is local to your system and only works for you, not for collaborators working with you on your repo.

My Excludes File and Explanations

Here are the contents of my excludes file:

node_modules
.env.local
.venv/
.vscode
GitIgnore.csproj

Why I've chosen to ignore these files:

node_modules: The local cache containing downloaded Node.js dependencies. Your package.json file and package manager lock files will include all the information required to install your project's dependencies on a given machine. In addition, the contents of node_modules are often specific to the system that the dependencies were installed on, and the folder can be massive in size.
.env or .env.local: A common location for secrets that must not be committed. The exact files to ignore depends on your project. I use Next.js App Router for most of my web dev projects, where the convention is to store secrets in .env.local while storing other environment variables in other .env files
.venv/: This is what I typically name my virtual environment directory when working with Python. Virtual environments should be created and activated separately on each collaborator's machine, and the directory should not be committed. Instead, commit just the requirements.txt file and use it to install pip packages inside the virtual environment.
.vscode: This directory includes things specific to the VSCode IDE (my preferred IDE), like folder-specific user settings and extension files.
GitIgnore.csproj: This serves a special purpose in that it allows me to alter the build process for C# project files in repos that I'm working with without needing to worry about accidentally committing these changes later. For example, when one of my C# projects relies on a different C# project as a project dependency, running dotnet build on my C# project will also build the dependency. If the dependency includes custom build steps, then those steps can cause my build to fail, but I can avoid this issue by copying the original project file to GitIgnore.csproj and removing those custom steps. This sort of scheme could also be useful in other languages that have their own project or package files.

Full NeoVim Config and Explanations for VSCode-NeoVim Users

JT Ziolo — Wed, 12 Jul 2023 01:24:58 +0000

Since around February of this year (2023), I've been doing most of my coding using the VSCode-NeoVim extension. For a while now, I've been interested in seeing what a plugin-enhanced NeoVim has to offer in terms of a full IDE experience. Unfortunately, every time I've tried to set up something like NvChad or LunarNvim, I've run into the same set of problems:

I don't need all of the plugins.
I don't know what many of the plugins are for.
I don't agree with the keybinds (they are almost always completely different than equivalent actions I've memorized when working in VSCode).

Even though I can fix all of the above, I don't want to spend a week doing that when:

I'm not the person who set up the plugins.
The NeoVim config code is split up across multiple files for some reason.
I have a working code editor already.

So until recently, I just stuck with VSCode-NeoVim. However, I recently had a breakthrough. After many phind searches and going through a lot of stack overflow posts of varying quality, I figured out how to set up NeoVim to include all the essential features of an IDE: a file browser, command palette, autocomplete, code actions, etc.

While doing so, I split up my init.lua file so that NeoVim will still work in VSCode-NeoVim.

My Configuration

Here is a gist containing my current init.lua file: https://gist.github.com/jt-ziolo/cac64c2d17d6036fc6a61a26898b91b2.

Here is a barebones example which shows how the init.lua file is set up:

vim.g.mapleader = " " -- Make sure to set `mapleader` before lazy so your mappings are correct

-- Set up lazy.nvim (the plugin manager)
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system({
        "git",
        "clone",
        "--filter=blob:none",
        "https://github.com/folke/lazy.nvim.git",
        "--branch=stable", -- latest stable release
        lazypath,
    })
end
vim.opt.rtp:prepend(lazypath)

if vim.g.vscode then
    -------------------------------------------------------------------
    -- The following applies ONLY for VSCode-NeoVim
    -- Everything under require("lazy") will be a subset of what is
    -- included in the settings for ordinary NeoVim
    -------------------------------------------------------------------

    require("lazy").setup({
        -- Plugin installs, which either just point to the github repo
        -- or which are based on lazy.nvim-specific instructions from
        -- the repo
    })

    -- Some settings can go here
    -- but I'm not sure what yet

    -- Requires
    -----------
    -- ex: require("hop").setup({})
    -- You will likely not put anything here
    -- ...

    -- Keybinds
    -----------
    -- ex: vim.keymap.set("n", "n", "nzz", {})
    -- ...
else
    -------------------------------------------------------------------
    -- The following applies ONLY for ordinary Neovim outside of VSCode
    -------------------------------------------------------------------

    require("lazy").setup({
        -- Plugin installs, which either just point to the github repo
        -- or which are based on lazy.nvim-specific instructions from
        -- the repo. The difference here is that you include plugins
        -- related to LSP functionality, code completion, etc.
    })

    -- Some settings can go here
    -- ex: vim.diagnostic.config({ virtual_text = false })

    -- Requires
    -----------
    -- ex: require("onedark").load()
    -- ...

    -- Keybinds
    -----------
    -- ex: vim.keymap.set("n", "<leader>i", "<cmd>Neoformat<CR>", { desc = "Neoformat" })
    -- ...
end

-------------------------------------------------------------------
-- The following applies for BOTH VSCode and ordinary Neovim
-- Note that we cannot call require("lazy").setup here,
-- so load your plugins in the prior two sections
-------------------------------------------------------------------

-- Requires
-----------
-- ex: require("hop").setup({})
-- ...

-- Keybinds
-----------
-- ex: vim.keymap.set("n", "n", "nzz", {})
-- ...

What the Plugins Do

First off, let's define what "LSP" means:

The Language Server Protocol (LSP) defines the protocol used between an editor or IDE and a language server that provides language features like auto complete, go to definition, find all references etc. (https://microsoft.github.io/language-server-protocol/)

Many of the plugins that I will list are focused on LSP management and integration, so knowing what is meant by LSP will help you as you read through plugin documentation.

Here is a list of the important plugins and what they do, in terms that someone coming from VSCode could understand. Note that I have listed just the particular plugin that I'm currently using, but multiple options may exist. For example: snippy is just one option for adding a snippet system, other options I know of are vsnip, ultisnips, and luasnip and I'm certain that there are others out there.

Repo	What It Does
"dcampos/nvim-snippy"	Provides a snippet system
"dcampos/cmp-snippy"	Integrates the snippet system with suggestions/autocomplete as you type
"hrsh7th/cmp-cmdline"	Suggestions/autocomplete for NeoVim commands as you type (e.g. :write)
"hrsh7th/cmp-buffer"	Suggestions/autocomplete for searches (/ and ?) as you type
"hrsh7th/cmp-nvim-lsp"	Dependency for some plugins that interface with the LSP
"rsh7th/nvim-cmp"	Dependency for previous 3 plugins
"jay-babu/mason-null-ls.nvim"	Sets up Mason to work with null-ls
"jose-elias-alvarez/null-ls.nvim	Dependency that is required by plugins which need to access code completion, warnings/errors (diagnostics), code actions, and related suggestion functionality
"neovim/nvim-lspconfig"	Dependency that allows code completion, warnings/errors (diagnostics), code actions, and related suggestion functionality. Its an official neovim plugin.
"nvim-lua/plenary.nvim"	A library of helper functions for neovim that is required by many plugins.
"nvim-telescope/telescope.nvim"	Think of it as a replacement for the command palette.
"nvim-tree/nvim-tree.lua"	A replacement for the explorer menu.
"nvim-treesitter/nvim-treesitter"	Dependency which manages and provides access to the syntax tree for the current file, which is needed by plugins for things like detecting syntax errors, figuring out where an editor symbol is located in files, etc.
"sbdchd/neoformat"	Formats files using any formatters you have installed.
"williamboman/mason-lspconfig.nvim"	Allows the NeoVim LSP service to "see" the LSPs installed via Mason.
"williamboman/mason.nvim"	Used to install/update formatters, LSPs, debuggers, and linters. Those things won't actually work without you installing other plugins, though.
"akinsho/bufferline.nvim"	The tab bar on top of your editor, showing open tabs (buffers)
"folke/zen-mode.nvim"	Zen mode
"nvim-lualine/lualine.nvim"	The bottom bar that shows your current mode, the file name, scroll percentage, line/character number, git status, etc.
"nvim-tree/nvim-web-devicons"	Dependency that is used to provide icons next to files for nvim-tree, and which is used by many other plugins as a source of devicons.
"nvimdev/lspsaga.nvim"	Provides a better experience for things like renaming symbols, getting a floating terminal, showing a menu for the symbol under the cursor, etc. I use it mainly for navigating errors/warnings (diagnotics) with quick access to code actions. The documentation is full of screenshots: https://dev.neovim.pro/lspsaga/
"onsails/lspkind-nvim"	Adds symbols to the suggestion/autocomplete window
"tpope/vim-eunuch"	It lets you change the currently opened file, including renaming, changing permissions, deletion, etc. I'm not sure why it's called eunuch either, but it's made by tpope, and everything he makes is gold.
"windwp/nvim-autopairs"	Auto-closes quotes, braces, parentheses, etc.
"windwp/nvim-ts-autotag"	Auto-closes HTML, XML, and other markup tags as you type them.

I hope that this post helps you understand the role of each plugin, while avoiding the annoying experience of searching around for answers about what X error message means, figuring out what a plugin does, reading through pedantic responses about how it should be so clear and obvious to do something based on NeoVim's documentation... etc.

Why is It So Complicated?

One concept that some readers may struggle with (and which I had also struggled with) is why so many plugins are needed to get basic IDE features.

NeoVim, like vim, is minimalistic in its design. Out of the box (without any plugins installed), NeoVim is a very simple editor with modal text editing capabilities, sort of like Notepad++. Maybe this is all you want or need. For example, you don't need those IDE features if you only install NeoVim as a dependency for VSCode-NeoVim (nor would you want it, since they would probably conflict with VSCode).

However, if you do want IDE features, NeoVim's plugin capabilities and ecosystem are mature enough that you can add them. This allows you to set up a custom configuration tailored to your use, without the bloat of unused features or plugins.