When the Same "Digital Key" Ends Up in Too Many Hands: The Hidden Risk of Duplicate SSH Certificates

Most people have never heard of SSH, but almost every website, app, and company you interact with relies on it behind the scenes. SSH (Secure Shell) is the technology system administrators use to log into servers securely over the internet — think of it as the locked, private doorway that engineers use to manage the computers running the internet.

Like any lock, SSH depends on keys. And like any lock, if two doors end up sharing the exact same key, you have a problem — even if nobody did it on purpose.

This article explains what "duplicate SSH keys" (sometimes called duplicate certificates) actually are, why they quietly show up more often than people realize, what damage they can cause, and — importantly — why this is not just a technical problem but a policy and governance problem too.

A Simple Analogy First

Imagine a hotel where every room is supposed to have its own unique key. Now imagine the hotel got lazy during construction and used a machine that, by mistake, cut a hundred identical keys instead of a hundred different ones. Every room looks different, every door looks locked and secure — but one key opens all of them.

That's essentially what happens with duplicate SSH keys. Two servers that are supposed to be completely separate, with their own unique "lock and key," end up sharing the same key by accident. Anyone holding that one key can now get into both.

How Does This Actually Happen?

Nobody sits down and deliberately creates duplicate keys. It happens through shortcuts and automation gone slightly wrong. The most common cause:

Copy-paste computers. When companies set up new servers, they rarely build each one from scratch. Instead, they create one "template" server, get it working perfectly, and then clone it hundreds or thousands of times to save time — this is completely normal and efficient. The problem is that if the original template already generated its own security key before it was cloned, every single copy inherits the exact same key. It's like photocopying a signed, unique ID card a thousand times instead of issuing a thousand different ones.

This isn't a rare, theoretical problem. Cloud companies like DigitalOcean have publicly acknowledged finding this exact issue in their own systems and had to change how they build servers to fix it. Security researchers regularly scan the internet and find thousands of unrelated devices — often cheap smart devices from the same factory — all quietly sharing identical keys.

Weak randomness when the key was created. A security key is only unpredictable if it's generated using genuinely random data. In 2008, a mistake in a popular piece of software (used by Debian and Ubuntu, two widely-used operating systems) accidentally crippled the randomness used to generate these keys. For about two years, every key created on affected systems came from a tiny, predictable pool of possibilities — small enough that someone could simply guess or precompute them. It's the equivalent of a lock company accidentally making only a few thousand possible key shapes instead of billions, without telling anyone.

A shared "master key" system that isn't locked down properly. Larger, more modern companies now often use a central authority that issues short-term digital certificates instead of handing out permanent keys (similar in spirit to how a hotel might use programmable key cards instead of physical keys, each one only working for your stay). This is a big security improvement — but it introduces one new risk: if someone steals the master machine that programs all those key cards, they can create a valid card for any room in the hotel, instantly, without anyone noticing something is wrong. In other words, centralizing trust makes day-to-day security easier, but it also creates one very high-value target.

Why This Is Dangerous, in Plain Terms

• Someone could pretend to be a legitimate server. If an attacker gets hold of a duplicated key, they can set up a fake server that looks completely legitimate to anyone connecting to it — because the "key" matches exactly what people expect. This is called impersonation, and it can be used to steal information or spy on communications.
• It becomes impossible to tell who did what. If many people or many machines are all using the same shared key, it's like a hundred people sharing one hotel key card. When something goes wrong, there's no way to know who actually walked through the door. This destroys accountability — a core requirement of good security.
• One mistake can compromise everything at once. In the newer "master key card" systems, a single breach at the top doesn't just compromise one server — it can potentially compromise every server that trusts that central system. The convenience of centralized management is also its biggest weakness if it isn't protected properly.
• People stop paying attention to warnings. When systems are cloned often, administrators start seeing "this key has changed, are you sure you trust this server?" warnings all the time as routine noise — and learn to click "yes" without thinking. That's a problem, because that exact warning is also what would alert them to a real attack. Familiarity breeds carelessness.

Why This Keeps Happening: It's Not Just a Tech Problem

Here's the part that often gets missed: this isn't really a story about bad code or weak encryption. SSH's underlying technology is sound. The real issue is organizational — companies don't always have clear rules, ownership, or oversight for how these digital keys are created, tracked, and retired.

A few reasons this keeps slipping through the cracks:

• No one owns the problem. The team that builds and clones servers is usually different from the team responsible for security policy. Cloning servers quickly is the engineering team's goal; making sure every key is unique is the security team's goal — and if nobody explicitly connects those two responsibilities, duplication happens by default.
• Nobody's checking. Unlike some other types of security certificates (like the ones your web browser checks when you visit a website), there's no public, searchable record of SSH keys. A company usually only discovers it has duplicate keys if it actively goes looking — and many never do until something breaks or a researcher points it out.
• Rules exist, but they're vague. Government and industry security standards typically say organizations must manage their digital keys properly, but they rarely spell out specific, concrete rules for this type of key the way they do for other, more visible types of certificates. That leaves it up to each organization's own discipline and awareness — which varies enormously.

What Organizations Should Actually Do

On the technical side:

• Make sure every new server generates its own fresh key the first time it starts up — never let a clone inherit its "parent's" key.
• Give every person and every automated system its own individual key — never share one key across multiple users.
• Regularly scan your own systems to check that no two machines have accidentally ended up with the same key.
• If using a central "master key" system, protect it like the crown jewels — strict access controls, monitoring, and short-lived certificates that expire quickly rather than lasting forever.

On the policy side:

• Put a clear, written policy in place specifically for how these digital keys are created, tracked, rotated, and retired — don't assume general security policy already covers it.
• Assign clear ownership so it's obvious whose job it is to catch this before it becomes a problem.
• Build regular audits into your compliance process, even if regulators don't explicitly demand it yet.
• Treat a breach of the central "master key" system as a top-tier incident in your response planning, given how much damage it can cause compared to a single leaked key.

The Bottom Line

Duplicate SSH keys are a quiet, easy-to-overlook risk precisely because nothing about them looks broken — the servers work fine, users log in without issue, and everything appears secure on the surface. The danger only becomes visible when someone deliberately looks for it, or when it's too late. Closing this gap isn't about better cryptography; it's about better housekeeping, clear ownership, and policies that keep pace with how modern infrastructure is actually built.

If your organization would like help assessing exposure to this issue, reviewing your key and certificate management policies, or responding to a suspected incident, you can book a consultation call or send an enquiry to info@thecyberdiplomat.com.