Dev

Dummy SSH Key Pair Generator

The dummy SSH key pair generator produces realistic-looking fake SSH public keys in ED25519, RSA, and ECDSA formats — ready for use in documentation, test fixtures, and infrastructure code without exposing real credentials. When building Terraform modules, Ansible roles, or Kubernetes manifests that accept SSH public key inputs, you need syntactically valid-looking strings that pass format checks. Placeholder text like 'INSERT_KEY_HERE' breaks validation; a properly structured fake key doesn't. Each generated key follows the real format: a key-type prefix, a Base64-encoded body of the correct approximate length, and a trailing comment field. ED25519 keys produce the compact 68-character body you'd see in practice, while RSA keys generate the longer 372-or-more character Base64 block typical of 2048-bit keys. ECDSA keys match the nistp256 curve structure. The comment field defaults to user@example.com but accepts any string — useful for labeling keys by environment or role in your docs. You can generate up to a batch of keys at once, which speeds up seeding test databases, populating authorized_keys fixture files, or creating multi-user infrastructure examples. Because these keys are not cryptographically derived, they will never authenticate against any server, making them safe to commit to public repos or paste into documentation. This tool is particularly useful for teams writing tutorials, API documentation, or onboarding guides where real key exposure would be a security risk. Infrastructure engineers can also use it to pre-fill Terraform variable files and CI pipeline templates before real keys are provisioned.

How to Use

  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 in SSH server integration tests
  • •Populating Terraform variable files before real keys are provisioned
  • •Filling in SSH key fields in API documentation and OpenAPI examples
  • •Creating multi-user Ansible inventory examples with distinct per-user keys
  • •Testing form validation that checks SSH public key format in web apps
  • •Providing safe placeholder keys for public GitHub tutorial repositories
  • •Generating labeled keys per environment in infrastructure onboarding guides
  • •Pre-filling Kubernetes Secret manifests for SSH-based Git clone configurations

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

Can I use these fake SSH keys for actual server authentication?

No. These keys are not cryptographically generated, so there is no corresponding private key and they will never authenticate against any SSH server. They are structurally formatted to look valid and pass regex or length checks, but attempting to use them for real authentication will always fail. They are safe for testing, documentation, and placeholders only.

Will these fake keys pass SSH key format validation?

They are designed to pass basic format validation — correct prefix, realistic Base64 body length, and a valid comment field. However, some stricter validators perform cryptographic checks (such as verifying the key can be decoded into a valid curve point), which these keys will not pass. They work well for UI form validation, regex checks, and documentation rendering.

What is the difference between ED25519, RSA, and ECDSA key types?

ED25519 is a modern elliptic-curve algorithm producing short, fast keys and is the current best-practice recommendation. RSA is the long-standing standard, typically 2048 or 4096 bits, with a much longer Base64 body. ECDSA uses elliptic curves like nistp256 and sits between the two in length. All three are widely supported, but ED25519 is preferred for new deployments.

How do I add a custom comment to the SSH key?

The Key Comment field accepts any string — it becomes the trailing label on the public key line after the Base64 body. Real keys typically use user@hostname format, but you can enter anything useful: deploy@production, ci-bot, or a team email. The comment does not affect the key's format validity and is purely informational.

Is it safe to commit these fake SSH keys to a public GitHub repo?

Yes. Because these keys have no associated private key and cannot authenticate against any server, committing them publicly carries no security risk. This makes them ideal for tutorial repos, public infrastructure examples, and open-source documentation where real keys should never appear.

How many fake SSH keys can I generate at once?

Use the count input to set how many keys to generate in one batch. This is useful when you need to populate a fixture file with multiple distinct keys, simulate an authorized_keys file with several users, or create a Terraform list variable with several example entries at once.

Why does my RSA fake key look so much longer than the ED25519 key?

That is expected and matches real key proportions. An ED25519 public key Base64 body is around 68 characters because the underlying key material is only 32 bytes. An RSA-2048 public key encodes a 2048-bit modulus plus exponent, producing a Base64 body of roughly 370 characters or more. The generator mirrors these real-world length differences.

Can I use these keys in Terraform to test modules that take SSH key inputs?

Yes, this is a primary use case. Paste a generated key as the value for variables like public_key in an aws_key_pair resource or similar. The key will satisfy string and format checks during plan and apply dry-runs without requiring you to expose or generate a real key pair during development.