Skip to main content
Back to Dev generators

Dev

Dummy SSH Key Pair Generator

Used by developers, writers, and creators worldwide.

The dummy SSH key pair generator creates realistic-looking fake SSH public keys in ED25519, RSA, and ECDSA formats for documentation, test fixtures, and infrastructure code. Placeholder strings like INSERT_KEY_HERE break format validation in Terraform, Ansible, and Kubernetes manifests. A properly structured fake key does not. Each generated key follows real structure: a key-type prefix, a Base64 body of accurate length, and a trailing comment field. The comment defaults to user@example.com but accepts any string — deploy@prod, ci-bot, whatever fits your context. Generate up to a batch at once to seed fixture files or populate multi-user infrastructure examples quickly. No real credentials are ever created.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Select a key type from the dropdown — choose ED25519 for modern short keys, RSA for long traditional keys, or ECDSA for curve-based keys.
  2. Set the count field to how many fake keys you need, for example 3 for a multi-user fixture file.
  3. Enter a custom comment in the Key Comment field to label keys by role or environment, such as deploy@staging.
  4. Click Generate to produce the batch of formatted fake SSH public key strings.
  5. Copy individual keys or the full list and paste them into your config files, docs, or test fixtures.

Use Cases

  • •Seeding authorized_keys fixture files for SSH server integration tests in CI pipelines
  • •Pre-filling Terraform aws_key_pair variables before real keys are provisioned
  • •Populating OpenAPI and API docs examples with structurally valid SSH public key strings
  • •Creating multi-user Ansible inventory examples with distinct labeled keys per role
  • •Testing SSH key format validation in web app forms using Cypress or Playwright

Tips

  • →Use distinct comments per key (web@prod, deploy@staging) when seeding multi-user fixtures — it makes test output easier to trace.
  • →ED25519 keys are the safest default for documentation: they look modern, are short enough to display in a single line, and match what most current tutorials show.
  • →When testing Terraform modules locally, paste a fake RSA key into a terraform.tfvars file so plan output shows realistic key lengths without a real keypair.
  • →If your form validator rejects these keys, switch to RSA — some older validators were written expecting the longer RSA Base64 body and reject shorter ED25519 strings.
  • →Generate a batch of 5 or more keys at once and store them in a keys.json fixture file in your test suite so the same realistic-looking values are reused across all tests.
  • →Avoid using user@example.com as the comment in public-facing documentation — swap it for a role-based label like ci-bot@yourorg to reinforce good key hygiene habits for readers.

FAQ

will these fake ssh keys pass format validation checks

They pass basic format checks — correct key-type prefix, realistic Base64 body length matching the selected algorithm, and a valid comment field. UI form validators and regex-based checks will typically accept them. However, stricter cryptographic validators that verify the key can be decoded into a valid curve point will reject them. For most testing and documentation use cases — Terraform plan runs, OpenAPI rendering, fixture files — they work without issue.

is it safe to commit dummy ssh keys to a public github repo

Yes. These keys are not cryptographically derived, so there is no corresponding private key and they cannot authenticate against any SSH server. Committing them publicly carries no security risk, which makes them ideal for tutorial repos, open-source infrastructure examples, and onboarding guides where real keys should never appear. They are safe to paste into documentation, CI templates, or any public-facing code.

what is the difference between ed25519 rsa and ecdsa for fake test keys

The key type affects the format and length of the generated output, mirroring real-world proportions. ED25519 produces a compact Base64 body of around 68 characters. RSA generates a much longer block — roughly 370 characters for a 2048-bit key — because it encodes a large modulus and exponent. ECDSA using nistp256 falls between the two. Choose the type that matches what your validator, documentation, or infrastructure template expects to see.