I suggest you don't sync SSH keys. That's just increasing the blast radius of any one of those machines being compromised.
this post was submitted on 10 Oct 2023
50 points (96.3% liked)
Linux
48314 readers
83 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Exactly this. Don't move private keys between machines. Generate them where you need them, it's not like they cost anything
I mean, you want to copy the public keys that represents your machines, right?
Fair point, but I would equate that with syncing the authorized_keys file rather than thinking about how to sync the keys.
Right. Use some kind of centralized authentication like freeipa.
For bash aliases, I just pull down a .bashrc from github gists.
OP should just generate a unique SSH key per device (+ user).
Agreed. I’ve probably got 100 keys registered with GitHub and 98 of them the private key is long destroyed due to OS reinstalls or whatnot. Format machine, new key. New machine, new key.
FYI: You can remove the old keys from GitHub.
I like to save them for a rainy day when I need an OCD fix.
I d rather have 2 to 3 (for critical, mid, and test systems) ssh keys that are regularly rotated than 1 key per machine. I m not gonna balance 50 ssh keys; neither enter my password every time i jump hosts.
Is the url is easy to rember?
Dotfiles go in git, SSH keys are state.
I'm looking to migrate to home-manager though because I use Nix on all my devices anyways.
Home manager is great
I also have multiple versions of by bash_profile with syntax specific to the OS. It checks if we're on MacOS or Linux with a kernel check and then reads the appropriate ancillary bash_profile for that platform. Anything that can live in the main bash_profile with the same command on both platforms lives there and anything that needs to be system-specific is in the other one.
I have all my important functions as individual files that get loaded with the following:
function loadfuncs() {
local funcdir="$HOME/.dotfiles/functions/"
[ -e "${funcdir}".DS_Store ] && rm "$HOME/.dotfiles/functions/.DS_Store"
local n=0
for i in "${funcdir}"*; do
source "$(realpath $i)"
n=$(( n + 1 ))
done
}
loadfuncs
Interesting way to go about it. Though when I'm at the point where I need differences between linux and darwin, I'm probably going to do that at the home-manager level.
Just for fun, here's how I'm checking that (this was written in 2016 and may require adjusting as I haven't been keeping up on Linux for a while):
function oscheck() {
if [[ "$(uname -s)" == 'Darwin' ]]; then
# echo Darwin
osType=Darwin
return 0
elif
[[ "$(uname -s)" == 'Linux' ]]; then
# echo Linux
osType=Linux
grep CentOS /etc/os-release > /dev/null
if [[ "$?" == 0 ]]; then
# echo "CentOS"
export theDistro=CentOS
return 0
else
:
fi
grep Ubuntu /etc/os-release > /dev/null
if [[ "$?" == 0 ]]; then
export theDistro=Ubuntu
return 0
else
:
# echo "Not Ubuntu"
fi
printf " %s\n" "Error: osType tested true for Linux, but did not find CentOS or Ubuntu." ""
return 1
else
osType=Unknown
return 1
fi
}
oscheck
Checking for Ubuntu or CentOS is a tad limiting given the amount of distros there are ;)
Yeah, but those were the two I was using. I didn't mean to suggest that the code, as is, was correct for everyone. ;-)
I'm surprised no one mentioned ansible yet. It's meant for this (and more).
By ssh keys I assume you're talking about authorized_keys, not private keys. I agree with other posters that private keys should not be synced, just generate new ones and add them to the relevant servers authorized_keys with ansible.
I use Ansible for this as well. It's great. I encrypt secrets with Ansible vault and then use it to set keys, permissions, config files, etc. across my various workstations. Makes setup and troubleshooting a breeze.
If the keys are password protected.... eh why not sync them.
Also ssh certificates are a thing, they make doing that kind of stuff way easier instead of updating known hosts and authorized keys all the time
Passwords will be brute forced if it can be done offline.
Private SSH keys should never leave a machine. If a key gets compromised without you knowing, in worst case you will revoke the access it has once the machine's lifespan is over. If you copy around one key, it may get compromised on any of the systems, and you will never revoke the access it has.
And you may not want to give all systems the same access everywhere. With one key per machine, you can have more granularity for access.
Passwords will be brute forced if it can be done offline.
Set a good high entropy password, you can even tie it to your login password with ssh-agent usually
Private SSH keys should never leave a machine.
If this actually matters, put your SSH key on a yubikey or something
If a key gets compromised without you knowing, in worst case you will revoke the access it has once the machine’s lifespan is over.
People generally don't sit on keys, this is worthless. Also knowing people I've worked with... no, they won't think to revoke it unless forced to
and you will never revoke the access it has.
Just replace the key in authorized_keys and resync
And you may not want to give all systems the same access everywhere
One of the few reasons to do this, though this tends to not match "one key per machine" and more like "one key per process that needs it"
Like yeah, it's decent standard advice... for corporate environments with many users. For a handful of single-user systems, it essentially doesn't matter (do you have a different boot and login key for each computer lol, the SSH keys are not the weak point)
This looks popular: www.chezmoi.io
+1 this, it is amazing. The scripting features are the cherry on top.
On my devices like PCs, laptops or phones, syncthing syncs all my .rc files, configs, keys, etc.
For things like servers, routers, etc. I rely on OpenSSH's ability to send over environmental variables to send my aliases and functions.
On the remote I have
[ -n "$SSH_CONNECTION" ] && eval "$(echo "$LC_RC" | { { base64 -d || openssl base64 -d; } | gzip -d; } 2>/dev/null)"
in whatever is loaded when I connect (.bashrc, usually)
On the local machine
alias ssh="$([ -z "$SSH_CONNECTION" ] && echo 'LC_RC=$(gzip < ~/.rc | base64 -w 0)') ssh'
That's not the best way to do that by any means (it doesn't work with dropbear, for example), but for cases like that I have other non-generic, one-off solutions.
Git and GNU stow.
I love this solution, I've been using it for years. I had previously just been using the home directory is a git repo approach, and it never quite felt natural to me and came with quite a few annoyances. Adding stow to the mix was exactly what I needed.
This is the only answer for me. Bonus points if your .login file does a background git pull.
Syncthing. If you want flatpak, syncthingy.
Its simply best, does all the annoying background things like webUI, machines, versioning, verifying etc. If you disable global discovery you can use it tough LAN only
Have you considered a shared folder with Syncthing?
That my solution. I have a 'Sync' folder on every device's Home folder, and then I use some aliases to determine whether to grab the bash_aliases file or replace it:
- alias dba='diff -s ~/.bash_aliases ~/Sync/.bash_aliases' # compare files
- alias s2ba='cp ~/Sync/.bash_aliases ~/' # Push from Sync folder to current bash aliases
- alias ba2s='cp ~/.bash_aliases ~/Sync/' # Push from current bash aliases to Sync folder
By far, the diff alias is the most used. It allows for a quick check on what is different between files w/o having to open them up
yadm
Yet Another Stow-Based Dotfile Sync Manager
yas-bdsm
I use it with GitHub, works amazing on multiple boxes, OSX and Linux. For SSH keys, just use KeePassXC and SyncThing.
I use a git repo combined with the basic install utility. Clone the repo, run the app installer, then run the install script. For symlinks I just use a zsh script.
Thanks that's a good idea.
I like this approach. Had never heard of those solutions. Thanks!
I keep my dotfiles in a got repo and just do a git pull your update them. That could definitely be a cron job if you needed.
SSH keys are a little trickier. I’d like to tell you I have a unique key for each of my desktop machines since that would be best practice, but that’s not the case. Instead I have a Syncthing shared folder. When I get around to cleaning that up, I’ll probably do just that and keep an authorize_keys and known_hosts file in git so I can pull them to needed hosts and a cron job to keep them updated.
ssh keys go into my keepass db, keepassxc imports them into gpg agent or ssh agent. Bash aliases and so on are in my dotfiles
My solution is not ideal:
I created a directory, called ~/config_sync. I create sym links for config files, like ~/.bashtc to ~/config_sync/bashrc
However, I need to record the sym links I've created, and repeat this process on new machines
Look into using GNU stow! It's exactly what you're doing but it creates the symlinks for you.
Use a git repo and stow tool. For updating, you only need run git pull (and stow if you create config for a new software). If you modify some config, just git add && git commit && git push.
With this way, you can also record change history of your config.
Several good suggestions on here already. Home manager might be another approach.
1password does this for me, when it comes to ssh keys, and it's great. All I have to do on a new machine is setup the ssh-agent, which is also practically preconfigured. The actual key never leaves the password manager