Its April Fool
Adding SSH keys to the YubiKey hardware security key provides convenience of SSH key use, especially when required for multiple computers.
Using a YubiKey to keep a single SSH key pair removes the need to generate a key pair for each computer.
Using one SSH key avoids the need for multiple entries in the allowed-signatures file to check locally that a commit has been signed.
Git Signed commits - local verificationλ︎
Practicalli has several computers (including smartphone and tablet) where commits are made from using an editor or command line tools.
An allowed-signatures file is used to check locally that a commit has been signed with a known SSH key and this is copied across all computers.
Viewing a commit in an editor or via the Git CLI will check the signatures in allowed-signatures and ensure report if the commit signing key is known
comments in allowed-signatures file
The allowed-signatures file can include # comment lines.
# ---------------------------------------------------------
# Allowed SSH keys for Git commit signing
#
# - Used locally to check commits are signed by a known key
# - no space allowed after comment - invalid key error
# ---------------------------------------------------------
# RangerOne
engineering@practical.li ssh-ed25519 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx engineering@practical.li
No blank lines allowed after comment lines
If there is a blank line after any comment line, then an invalid key error is reported.
AstroNvim 4 releasedλ︎
The version 4 release is a significant change to AstroNvim, the configuration provided in AstroNvim 3 into their own plugins.
- astrocore.lua
- astrolsp.lua
- astroui.lua
AstroNvim 4 is now a user configuration that pulls in the core AstroNvim plugins. This approach provides a single configuration that is simple to install, configure and extend.
To get started, fork the AstroNvim 4 user template repository to your own GitHub repository.
Alternatively, use the Practicalli AstroNvim user config repository, which is a fork of the AstroNvim user template, adding Clojure and other nice tools automatically.
Creating Practicalli astronvim-user-configλ︎
After a few days experimentation with AstroNvim 4 there are still some changes being made and potential for the AstroNvim user configuration to be altered.
Therefore a goal of the Practicalli astronvim-user-config is to minimise the changes to the original user template.
user.luaλ︎
lua/plugins/user.lua contains several examples of adding and overriding existing plugins.
Rather than change this file, I created separate config files in lua/plugins/ directory. Each new file contains a line that can disable the configuration
Instruct Neovim to ignore config
Add the following to the start of a configuration file to return an empty table, {}, ignoring any other configuration in that file.
practicalli.luaλ︎
Configuration that contains my own personal preferences, which can easily be disabled by removing the comment on the if statement line.
- add custom practicalli logo for startup
- add better-escape with
fdkey binding,jkis the AstroNvim default
LSP conflictλ︎
When initially enabling the plugins/user.lua configuration, the Noice plugin added via an AstroNvim Community import in lua/community.lua started reporting a conflict error.
LSP signature help conflict reported by noice plugin
The root of the conflict was the Discord "andweeb/presence.nvim" plugin, which included configuration to set a lsp handler
Presence plugin sets LSP signature help
The Discord plugin is not required so the plugin configuration was commented in lua/plugins/user.lua
Should both plugins been needed, then the Noice plugin warning can be managed by disabling its LSP signature
Disable Noice LSP Signature
{
"folke/noice.nvim",
event = "VeryLazy",
dependencies = { "MunifTanjim/nui.nvim" },
opts = function(_, opts)
local utils = require "astrocore"
return utils.extend_tbl(opts, {
lsp = {
-- override markdown rendering so that **cmp** and other plugins use **Treesitter**
override = {
["vim.lsp.util.convert_input_to_markdown_lines"] = true,
["vim.lsp.util.stylize_markdown"] = true,
["cmp.entry.get_documentation"] = true,
},
-- config.lsp.signature.enabled = false
-- signature = {
-- enabled = false,
-- },
},
presets = {
bottom_search = true, -- use a classic bottom cmdline for search
command_palette = true, -- position the cmdline and popupmenu together
long_message_to_split = true, -- long messages will be sent to a split
inc_rename = utils.is_available "inc-rename.nvim", -- enables an input dialog for inc-rename.nvim
lsp_doc_border = true, -- add a border to hover docs and signature help
},
})
end,
},
Neovim optionsλ︎
Space u w to toggle text wrap, which I find useful for Markdown and other content file types.
Vim options set in astrocore plugin
Set wrap to true in lua/plugins/astrocore.lua
-- vim options can be configured here
options = {
opt = { -- vim.opt.<key>
relativenumber = true, -- sets vim.opt.relativenumber
number = true, -- sets vim.opt.number
spell = true, -- sets vim.opt.spell
signcolumn = "auto", -- sets vim.opt.signcolumn to auto
wrap = true, -- sets vim.opt.wrap
guifont = "Fira Code:h16", -- neovide font family & size
},
Neo-tree configλ︎
H in Neotree to toggle hidden files and directories
Looking at the Neo-tree config examples, hidden files can be configured to show in the tree view using a different style, e.g a very subtle colour
Configure Neo-tree hidden files
A configuration to try
return {
"nvim-neo-tree/neo-tree.nvim",
config = function ()
require("neo-tree").setup({
filesystem = {
filtered_items = {
visible = true, -- when true, they will just be displayed differently than normal items
hide_dotfiles = false,
hide_gitignored = true,
hide_hidden = true, -- only works on Windows for hidden files/directories
hide_by_name = {
--"node_modules"
},
hide_by_pattern = { -- uses glob style patterns
--"*.meta",
--"*/src/*/tsconfig.json",
},
always_show = { -- remains visible even if other settings would normally hide it
--".gitignored",
},
never_show = { -- remains hidden even if visible is toggled to true, this overrides always_show
--".DS_Store",
--"thumbs.db"
},
never_show_by_pattern = { -- uses glob style patterns
--".null-ls_*",
},
},
},
})
end
}
SSH key and YubiKeyλ︎
Use the ,,, key type to create an SSH key pair that will be resident on a FIDO2 supporting hardware key, e.g. a recent YubiKey
Generate a FIDO2 Compliant resident key
-O resident indicates the key should be stored on the FIDO authenticator.
Resident key is easier to import to a new computer as they can be loaded directly from the hardware security key using ssh-add -K or ssh-keygen -K.
-K option loads resident keys from a FIDO authenticator.
For ssh-add, resident keys are downloaded from a FIDO authenticator. Public and private key files are written to the current directory for each downloaded key. If multiple FIDO authenticators are attached, keys will be downloaded from the first touched authenticator. See the FIDO AUTHENTICATOR section for more information.
TODO: Review wich YubiKey variants are FIDO2 compatible
Thank you.
Practical.li Website