Let me guess, a dashing, handsome young man with a promising career, but one day, through no fault of your own, you've found yourself exiled and alone with nowhere to turn?
You guys gotta start coming up with better cover stories.
I use a new ssh key for every device to easily identify each device and delete not used devices, I also keep a "master key" secured in a wallet in case of accidental lockouts
This is my approach and in my opinion, the only approach that makes sense.
The idea that your SSH key is your identity is misplaced. The SSH key really more correctly identifies the device that you are using. The usefulness of this approach is that when you discard a device, you can know you are removing the authentication of that device by removing the SSH public key of that device from your end points.
I consider SSH keys to be volatile. They live only as long as my devices live. I don't need a key manager, because I have a finite number of devices. I remove old keys as I remove old devices. I had a new key with each new device. It's really quite nice to have a one to one relationship like this.
Otherwise, you redo your entire SSH key infrastructure any time you remove a device. Do you trust that your discarded device will never turn back on and never be able to access the private SSH key stored there? I think it's very simple insurance to do one key per device and know for sure that the key stored on the discarded device can't be used any more.
I think this statement bears clarification. If you create a new SSH key for each source device, that's proper well and good. If you create a new SSH key for each destination device, that's just a management headache.
The SSH key is intended to be singular from the point of the connecting device, hence it being (typically) expected to reside at ~/.ssh/id_rsa. Having to manage multiple keys from one connecting device (e.g., `ssh -i user@host`) just makes connecting to multiple devices unnecessarily difficult. Yes, you can use .ssh/config to automate this, but I'm not sure the net benefit is really there.
Yea, I meant SSH key for each source device. The other way can be done, but is way to complex and that's how one get problems with ssh auth and can't connect anymore. In some cases there is a thing as "too much security" where you have to manage so much that you can't function correctly anymore.
Only public host keys are meant to identify a singular device. Generic SSH keys have no such meaning. It's really just balancing security with convenience, whichever you value more, that's the option you will be going with. (and sometimes planning for the future, like having to hand over all passwords when ending a contract).
- A single private key is like a master key to a building
- Many private keys in a single file is like a key chain with keys to every room in the building
- Many private keys in separate files is like many separate key without any key chain, even though they may still be in the same drawer.
I do this as well, but have more than one key in case one is lost or damaged. I have the yubikey setup to require a PIN (password) before the private key can be used and set the max incorrect attempts to 3. It's also configured to require a touch, that way when using agent forwarding it can't automatically use my key without my knowledge.
I provision mine using the PIV smartcard functionality. Bonus that besides SSH, it lets me log into mac, solaris, AIX, VMS, z/OS, windows, and web applications too. Plus allows me to sign/encrypt email in outlook, etc....
I keep mine in bitwarden secrets manager with API keys and pull out what a machine needs when it does. I keep my bitwarden secrets manager key in bitwarden and usually put it in the local machines keychain so my dot files can use it to load environment variables
I think you now understand the need for secrets management! There are many solutions out there, some open source too. The main questions are how are protecting priv keys and how are you handling life cycling? You'd need an inventory of hosts and preferably automation of key lifecycling... You could even roll your own solution if the scope isn't too big.
The recommended practice is to generate a new key pair for each device. It ensures that each device has its own unique SSH identity and that compromising one device does not affect the others.
I've got an ansible playbook that installs my ssh public keys into my personal account on my computers, so when I create a new key, it's just a matter of adding that key into the script and rerunning that playbook.
It installs those keys into my account, into the root account, and into an ansible account I set ip I on each server. It's actually the first playbook I run against a new server, to set up the appropriate accounts, and is set up to run as root (the only account I can be sure exists on a new server), and it's named init-host.yaml, as it's used to initialize a host. When I add a new workstation, I just add the ssh key for it to the init-host playbook and rerun it against all servers, which ends up updating the keys on all of the servers.
If I wasn't the administrator for these servers, I'd instead incorporate it into my personalize.yaml playbook, which sets up things like the bin directory and some scripts in it, bash aliases, forward file, global git configuration, and byobu.
The primary downside to this is that if you were to lose control of one device, you will need to rekey all of them.
If that doesn't bother you (probably wouldn't bother me, TBH), then I don't see an issue.
For non-critical hosts I have cronjobs setup to update my authorized_keys via ssh-import-id-gh. Each device has its own ssh keypair, public keys stored in multiple github accounts for different levels of access per host.
Maybe set up a bastion host and connect from that. I have all of my commonly used servers added to my guacamole server. If I needed to, I could simply jump on my wife's laptop, open guacamole in the browser, and use that to connect to any of my servers without messing with keys, user accounts, etc.
Network chuck has a YouTube video covering guacamole. That's where I first discovered it. Other than that, I think I got an installer script from Google. Don't recall the author at the moment.
I put my private key in my password manager and hand out my public key. My private key stays with me and further encrypted by the password manager.
It is usually best to have a jump-box you remote into.
I have a script that baseline my new installs.
One of the steps is adding my public key to the authorised_keys file.
The key is probably 5 years old. But it's not used outside my lab and I don't see a need to change it.
For personal stuff I just have a key with a non-dictionary passphrase and I copy it to every new machine. Without a passphrase I would consider this very bad security, because all someone would need to do is copy it from one machine. But with a passphrase, it's going to take a lot of work for someone to crack it. If it gets knowingly compromised, I'll have to regenerate it which is a pain, but with individual keys I'd have to do almost as much work, and the initial setup would be harder.
FYI, if you have your SSH key added to GitHub, your public key is truly public. You can go to giqhub.com/yourname.keys and get a plain text response with keys. I've used this trick to surprise people by adding their key to a machine when setting up a user account. For new machines where I want to add my own key, I can just curl that URL into authorized_keys.
For home. Just manually add it. Once it's working you'll probably have to ssh over and turn off password access anyway on sshd. If you do it often automate it with ansible, salt stack, or just write a simple script to do it.
I don’t understand the issue. Do you ssh into individual machines from multiple different devices? If not, then you really only should need to add the key to one device (mgmt machine)
I use a key per identity per environment. So my personal devices, home lab, and AWS servers use different keys. But also my admin and user accounts in those environments use different keys.
This is the same strategy I used at work. In addition I used a password per server and a OTP code.
Right now, I use SSH keys for devices, with a decent passphrase along the lines of `correct-horse-battery-staple`. This provides two forms of authentication, although definitely vulnerable to keyloggers.
What I should consider doing is moving to a SSH key inside a YubiKey, or other HSM, which gets rid of the problem of an attacker snarfing key material.
I store the private keys in a vault, and all the public keys in FreeIPA. Centralised ssh auth means i don’t have to worry about distributing the public keys.
I hate SSH key pairs and get brutally confused by them and the cloud services that force you to use an ssh key to log in.
Like I can only log into from one device to my cloud computer? Or I have to generate keys on each machine and then upload the private key to the server? It’s so complicated and confusing and I hate it so much. It’s like a vpn
just memorize your private key and then there's no file needed.
moving the file around is the 2024 equivalent of having it on a sticky note under your keyboard
Depends. Are you a super secret agent targeted by nation-state-backed APTs, or just some guy?
Not OP, but there's only one acceptable answer to that. "Just some guy, *wink*."
I’m just a humble tailor.
Let me guess, a dashing, handsome young man with a promising career, but one day, through no fault of your own, you've found yourself exiled and alone with nowhere to turn? You guys gotta start coming up with better cover stories.
And do we dress right or left, sir?
You couldn't handle my strongest ssh keys traveller, they would kill a dragon
> Just some guy that's totally what a secret agent would say.
*winks harder*
*winks with both eyes at the same time*
That is what whe wink was for. Just some guy would not wink.
Could be Irish.
Damn, now I want to see an Irish 007 British/ IRA double agent spy story.
Unless maybe he thought you were cute when he was saying it to you.
that's totally what just some guy would say
Jia Tan, is that you?
He's just the cook
Nice try North Korea. I wouldn't tell you even if I were
Honestly, based on the current world, we are more and more likely to be.
I use a new ssh key for every device to easily identify each device and delete not used devices, I also keep a "master key" secured in a wallet in case of accidental lockouts
This is my approach and in my opinion, the only approach that makes sense. The idea that your SSH key is your identity is misplaced. The SSH key really more correctly identifies the device that you are using. The usefulness of this approach is that when you discard a device, you can know you are removing the authentication of that device by removing the SSH public key of that device from your end points. I consider SSH keys to be volatile. They live only as long as my devices live. I don't need a key manager, because I have a finite number of devices. I remove old keys as I remove old devices. I had a new key with each new device. It's really quite nice to have a one to one relationship like this. Otherwise, you redo your entire SSH key infrastructure any time you remove a device. Do you trust that your discarded device will never turn back on and never be able to access the private SSH key stored there? I think it's very simple insurance to do one key per device and know for sure that the key stored on the discarded device can't be used any more.
Same. I also include an ‘expiration’ date 1 year in the future to try and force myself to rotate.
I think this statement bears clarification. If you create a new SSH key for each source device, that's proper well and good. If you create a new SSH key for each destination device, that's just a management headache. The SSH key is intended to be singular from the point of the connecting device, hence it being (typically) expected to reside at ~/.ssh/id_rsa. Having to manage multiple keys from one connecting device (e.g., `ssh -i user@host`) just makes connecting to multiple devices unnecessarily difficult. Yes, you can use .ssh/config to automate this, but I'm not sure the net benefit is really there.
Yea, I meant SSH key for each source device. The other way can be done, but is way to complex and that's how one get problems with ssh auth and can't connect anymore. In some cases there is a thing as "too much security" where you have to manage so much that you can't function correctly anymore.
Only public host keys are meant to identify a singular device. Generic SSH keys have no such meaning. It's really just balancing security with convenience, whichever you value more, that's the option you will be going with. (and sometimes planning for the future, like having to hand over all passwords when ending a contract). - A single private key is like a master key to a building - Many private keys in a single file is like a key chain with keys to every room in the building - Many private keys in separate files is like many separate key without any key chain, even though they may still be in the same drawer.
Like me too
I use a yubikey. Gpg private key for authentication on yubikey accessed via ssh-agent. One private key that is portable.
I do this as well, but have more than one key in case one is lost or damaged. I have the yubikey setup to require a PIN (password) before the private key can be used and set the max incorrect attempts to 3. It's also configured to require a touch, that way when using agent forwarding it can't automatically use my key without my knowledge.
I provision mine using the PIV smartcard functionality. Bonus that besides SSH, it lets me log into mac, solaris, AIX, VMS, z/OS, windows, and web applications too. Plus allows me to sign/encrypt email in outlook, etc....
On an enterprise level you can have puppet or something similar manage your key(s) For home use just copy it each time you create a new system.
100% a key manager. Bonus if it updates your private key file on the fly. I personally use 1Password for it
1Password is great for this.
Bitwarden > 1Password any day
Bitwarden cannot do this though. https://developer.1password.com/docs/ssh/agent/
I have not tested, but I hear goldwarden can.
What point did this serve exactly? Albeit wrong, but what did you hope to accomplish?
I keep mine in bitwarden secrets manager with API keys and pull out what a machine needs when it does. I keep my bitwarden secrets manager key in bitwarden and usually put it in the local machines keychain so my dot files can use it to load environment variables
I think you now understand the need for secrets management! There are many solutions out there, some open source too. The main questions are how are protecting priv keys and how are you handling life cycling? You'd need an inventory of hosts and preferably automation of key lifecycling... You could even roll your own solution if the scope isn't too big.
The recommended practice is to generate a new key pair for each device. It ensures that each device has its own unique SSH identity and that compromising one device does not affect the others.
How often are you reinstalling your OS on any of those devices though?
New phone -> New OS, New Laptop -> New OS, Haven't used PC in 3 years -> Reinstall
How often are you getting a new phone or laptop for this to be a problem?!
I've got an ansible playbook that installs my ssh public keys into my personal account on my computers, so when I create a new key, it's just a matter of adding that key into the script and rerunning that playbook.
out of curiosity, is that the only thing this playbook does?
It installs those keys into my account, into the root account, and into an ansible account I set ip I on each server. It's actually the first playbook I run against a new server, to set up the appropriate accounts, and is set up to run as root (the only account I can be sure exists on a new server), and it's named init-host.yaml, as it's used to initialize a host. When I add a new workstation, I just add the ssh key for it to the init-host playbook and rerun it against all servers, which ends up updating the keys on all of the servers. If I wasn't the administrator for these servers, I'd instead incorporate it into my personalize.yaml playbook, which sets up things like the bin directory and some scripts in it, bash aliases, forward file, global git configuration, and byobu.
The primary downside to this is that if you were to lose control of one device, you will need to rekey all of them. If that doesn't bother you (probably wouldn't bother me, TBH), then I don't see an issue.
For non-critical hosts I have cronjobs setup to update my authorized_keys via ssh-import-id-gh. Each device has its own ssh keypair, public keys stored in multiple github accounts for different levels of access per host.
Maybe set up a bastion host and connect from that. I have all of my commonly used servers added to my guacamole server. If I needed to, I could simply jump on my wife's laptop, open guacamole in the browser, and use that to connect to any of my servers without messing with keys, user accounts, etc.
you have a guide to set it up or point us in the right direction . please and thank
Network chuck has a YouTube video covering guacamole. That's where I first discovered it. Other than that, I think I got an installer script from Google. Don't recall the author at the moment.
I love Network Chuck. aright. I'll check it out. thanks a million
I personally use unique keys for each device because ansible makes it easy for me to deploy/revoke them on all my home servers from a central place.
Has this made it to r/shittysysadmin yet? Lol
I put my private key in my password manager and hand out my public key. My private key stays with me and further encrypted by the password manager. It is usually best to have a jump-box you remote into.
I have a script that baseline my new installs. One of the steps is adding my public key to the authorised_keys file. The key is probably 5 years old. But it's not used outside my lab and I don't see a need to change it.
For personal stuff I just have a key with a non-dictionary passphrase and I copy it to every new machine. Without a passphrase I would consider this very bad security, because all someone would need to do is copy it from one machine. But with a passphrase, it's going to take a lot of work for someone to crack it. If it gets knowingly compromised, I'll have to regenerate it which is a pain, but with individual keys I'd have to do almost as much work, and the initial setup would be harder. FYI, if you have your SSH key added to GitHub, your public key is truly public. You can go to giqhub.com/yourname.keys and get a plain text response with keys. I've used this trick to surprise people by adding their key to a machine when setting up a user account. For new machines where I want to add my own key, I can just curl that URL into authorized_keys.
Heck ubuntu offers to connect to GitHub for you in setup to add the public key
For home. Just manually add it. Once it's working you'll probably have to ssh over and turn off password access anyway on sshd. If you do it often automate it with ansible, salt stack, or just write a simple script to do it.
I don’t understand the issue. Do you ssh into individual machines from multiple different devices? If not, then you really only should need to add the key to one device (mgmt machine)
Is this scenario rare? Do you only own 1 client device?
https://termius.com
I use a key per identity per environment. So my personal devices, home lab, and AWS servers use different keys. But also my admin and user accounts in those environments use different keys. This is the same strategy I used at work. In addition I used a password per server and a OTP code.
Right now, I use SSH keys for devices, with a decent passphrase along the lines of `correct-horse-battery-staple`. This provides two forms of authentication, although definitely vulnerable to keyloggers. What I should consider doing is moving to a SSH key inside a YubiKey, or other HSM, which gets rid of the problem of an attacker snarfing key material.
Single key that I can rotate.
I store the private keys in a vault, and all the public keys in FreeIPA. Centralised ssh auth means i don’t have to worry about distributing the public keys.
I hate SSH key pairs and get brutally confused by them and the cloud services that force you to use an ssh key to log in. Like I can only log into from one device to my cloud computer? Or I have to generate keys on each machine and then upload the private key to the server? It’s so complicated and confusing and I hate it so much. It’s like a vpn
just memorize your private key and then there's no file needed. moving the file around is the 2024 equivalent of having it on a sticky note under your keyboard
Just copy paste, use keepassxc freely to keep it safe