Best way to manage SSH keys?
Suppose I've got multiple VPS that need to talk to each other. That means I need to stick the private key on the one server. But not super keen to have private keys floating around on VPS, especially since they're mostly without passphrase (VSS remote doesn't like it)
Googling suggests the answer lies in a combination of a trusted bastion host and ssh agent forwarding. Struggling to wrap my head around how that would look practically though. Especially in the context of automation i.e. not me initiating the action but rather VPS A deciding it needs to speak to VPS B at 3AM
Thoughts on this & related concepts?
Thanked by (1)uptime
Comments
Port knocking and ssh-agent. You can easily make VPS A download the private key, load it, then remove it after it's done but then you've got another cog in the works.
My pronouns are like/subscribe.
If you need the SSH key to do a specific command on other systems you can limit that key to only allow a specific command or set of commands.
Not sure if that would help for your task however it's one way to keep it safe if it's just specific commands that need to be ran such as a backup etc.
PureVoltage - Custom Dedicated Servers Dual E5-2680v3 64gb ram 1TB nvme 100TB/10g $145
New York Colocation - Amazing pricing 1U-48U+
Yeah was thinking of sticking it on a tmpfs. It's a bandaid though.
...there has to be a cleaner solution here somehow. I can see how they do it in a cloud context, but that assumes it's all in the same VPC. For separate random VPS that's not true (or wireguard it then I've got more private keys lol)
Didn't know that. Useful yes. I shall investigate. Thanks
No problem, it's so bloody useful for stupid little tasks you want done even more if using it on a bunch of VPS's should help save a lot of worries.![:) :)](https://lowendspirit.com/plugins/emojiextender/emoji/twitter/smile.png)
Glad I could help!
PureVoltage - Custom Dedicated Servers Dual E5-2680v3 64gb ram 1TB nvme 100TB/10g $145
New York Colocation - Amazing pricing 1U-48U+
I was looking at the documentation on https://linux.die.net/man/8/sshd and it seems in addition to restrict commands you can also restrict the use of keys to specific hosts and ports:
Nice one @beagle
With tight enough restrictions that might be enough. i.e. two sets of keys
1) mine
2) restricted VPS to VPS keys
I'm confused by why the private key needs to be moved at all. Installing the public keys for each host on each other host should be enough.
Kerberos and service accounts solve this problem, but that may be a deeper rabbit hole then you want to go down.
I found this which is pretty cool https://gist.github.com/sivel/c68f601137ef9063efd7
That may just be me insisting on playing life on hard mode. Open to other suggestions.
I want to set up a re-usable multi-purpose CI/CD pipeline. I need SSH to deploy from the CI/CD server to target. I can't see a way around the CI/CD server having keys for all the servers though. I'll likely also want the targets to be able to git clone off the CI/CD server so the reverse applies too, though that I can probably lock down pretty tight.
Just bind bash as uid 0 to a high port and block by default.
My pronouns are like/subscribe.
I am willing to bet your laptop has all sorts of untested and outright suspicious code running on it for years making it far less secure than a VPS set up with keeping private keys in mind. Yes hypervisor can always dump VPS's memory, but aside from obvious mistakes that's about it.
Fair point.
Keeping the keys on there but with precautions is probably the least painful route.
lol ... you will lose that bet.
(you don't know me ... or my laptop.)
HS4LIFE (+ (* 3 4) (* 5 6))
Gentoo built from source type?
can neither confirm nor deny ... but let's not derail this thread too much talking about my (Stallman-approved) Core 2 Duo thinkpad
HS4LIFE (+ (* 3 4) (* 5 6))
Yes for interactivity use ssh-agent, and for your automation put everything behind a VLAN. The only way into the VLAN should be through a jump host that you connect to with ssh pubkey authentication.
Practicing security through obscurity, aren't we ;-]