Not just that. Even if you don't make that mistake, having servers ssh into other hosts and leaving keys on them for this purpose means if one machine is compromised, others can be too. And they can use known_hosts to discover which ones.
There's another scary implication. If the user has set up SSH on their machines and added their own key as a valid key for logging in (for instance if you have 2 machines and you use the same SSH key for logging into everything), the attacker can log into the users own machine and compromise it. This makes remediation even more difficult because even after you have secured all the servers, the attacker can get back in through an affected user's machine.
That is not the only disturbing part. SSH private key by itself is not much of a threat, but bundled together with known_hosts is a recipe for disaster.
Though for new hosts people often don't verify the initial host key at all, just blindly accepting it, so that would be an extra risk vector.
Heck, I'm sure many don't bother verifying a new key when they get the warning, instead just removing the old from .ssh/known_hosts (or equivalent) to quiet the complaining! Though to be honest, with that security posture nothing is going to save them and our efforts are better spent securing others! I know at least one of our clients has automated systems that ignore key changes, because we once had a temporary config cockup that sent some connections to a host with the wrong key and some data was received there without any reported issues…
Exactly. Additionally, if I associate a new key pair with each host then I know I can discard + regenerate that key and it only affects that host. Each machine can have their own pairs as well.
If a key is compromised, it only provides access to a single host, not _all_ of them. This allows much more fine-tuned key management and reduces the scope of a key compromise.
Plus, it's not really that much more work. Just name your key after the host it's for, and then add an IdentityFile directive in your SSH config. I never have to worry about it, and get all the benefits.
You need to fully trust your target server, so you need to manage your known_hosts diligently and make sure you trust the host you connect to. If you just accept the host key without checking, you allow any host to use your SSH key for authentication. Any SSH server can accept your private key as authentication. Also, if the target host is infiltrated, it can use your private SSH key for authentication elsewhere without your knowledge.
Those keys can be worried about on a better secured computer, and don't need to be spread out on every frontend ssh server. Also it allows you to have each machine have a different host key pair, so if one leaks, only that single machine may have some trust issues, and not the whole fleet.
Also it's way better than TOFU, you can just add the CA key to known_hosts and avoid TOFU for each machine.
(Nevermind that you'll probably not accidentally commit some semi-ephemeral host key that's rotated often somewhere, because it will not be some special snowflake key you care about, but something handled by your infrastructure software automatically for each machine)
There's nothing wrong with adding your public key to many servers, as long as you keep the private key secure -- almost everyone does this. The article is discussing sharing of SSH host keys, which allows impersonation of an SSH server.
Right; but with agent forwarding, an 'evil' process on the target machine, that has privileges to connect to your agent socket (ie, root, or another pid as uid), can ask your agent to sign anything. Your key doesn't get exposed, but the agent will cheerfully sign requests no matter where they are going or where they came from.
So, say a virus, or a worm or something just went through your ~/.ssh/config file, your ~/.bash_history and/or your ~/.ssh/known_hosts (if you arn't using host name hashing) -- they could attempt to connect to all your previous hosts with your agent connection, and usually the agent won't offer any clue that this is ongoing ...
You can sometimes grab these ssh keys if the server has a severe directory traversal, local-file-inclusion vulnerability(run server/DB as root) , or to use for pivoting to different user/machine... But never heard of these being exposed outright.
If a bad guy gets root on one server you're currently connected via ssh with, and forwarding said key via, they can also access (unless otherwise firewalled) all systems that ssh key grants them access to.
Using a private key per system or set of systems means that such an attacker would only gain access to what that key grants them access to.
My "github" key only grants access to my github repos, not to my bitbucket repos or to my DigitalOcean servers, or my Scaleway servers.
I have an SSH key for each "thing", and each key is kept in a different keyring via https://github.com/ccontavalli/ssh-ident, _precisely_ to avoid that problem.
As an example, an attacker gaining root on my Oracle Cloud free server will not be able to clone all my Github repos with it: I only use that key to connect to that server, and while I may have the github key unlocked at the same time - that's on a different keyring which the server has no visibility of.
This can be a security risk if you're using the same SSH keypair for other things, and you're using a less secure algorithm than RSA or ED or similar. Anyone doing a bit of research about you might discover a vulnerable host for which the vulnerable algorithm keypair might be targeted
Look at the “shared responsibility model” - if someone got in through the host then I guess they’d investigate. If you leak your SSH private key it’s on you.
If an enemy takes control of just one of the hosts you ssh into, he will get your private key and can use it to ssh into any other box where you use RSAAuthentication.
Not necessarily. If you have multiple keys active in local your SSH Agent, then connect to a malicious host with Agent Forwarding enabled, the malicious host could try to connect to to a third host and I believe it will try to use all active keys from the local agent.
reply