Skip to content
OPS // KITitspentest.sh

E-SSH

ssh-keygen

Generate, inspect, and convert SSH key pairs during an engagement.

Official siteBack to catalog

OVERVIEW

ssh-keygen is OpenSSH’s (openssh.com) key management tool: it generates new key pairs, prints a key’s fingerprint, and converts between formats (PEM, RFC4716, PuTTY’s older `.ppk` needs a separate converter). On an engagement it shows up twice — provisioning a keypair for a client-authorized access method, and inspecting a key found as loot on a compromised host.

`ssh-keygen -lf <file>` prints the fingerprint of an existing public or private key without touching its contents, which is the safe first move on a recovered `id_rsa` or `authorized_keys` entry: confirm what it is and whether it matches a known account before doing anything else with it.

USE CASES

Practical use cases

  • 01

    Generating a fresh keypair for a client-authorized persistent access method.

  • 02

    Fingerprinting a recovered private or public key to see whether it matches a known account.

  • 03

    Checking the algorithm and bit length of a key found in a backup or config.

  • 04

    Converting a recovered key between PEM and OpenSSH formats before using it with other tools.

QUICK START

When an engagement needs an authorized SSH keypair provisioned for a documented access method, or when a recovered private/public key needs its fingerprint or format checked.

  1. Confirm whether the task is generating a new authorized access key or inspecting a recovered one — the rules of engagement differ for each.
  2. For generation, use a strong algorithm (ed25519) and a passphrase, and document where the key will be installed.
  3. For inspection, fingerprint the recovered key first; do not attempt to crack a passphrase unless that is explicitly in scope.
  4. Record every key you provision and remove it, along with its authorized_keys entry, at engagement end.
ssh-keygen — bash
ssh-keygen -t ed25519 -C "engagement-access" -f ./engagement_key

BEFORE YOU RUN IT

What to check before running it

Any keypair generated for engagement access must be documented in the report and its public key removed from authorized_keys when the engagement ends — an orphaned key is a standing access path.

A recovered private key may itself be a live credential; treat it under the same data-handling rules as any other secret and do not reuse it outside the authorized scope.

Attempting to crack a passphrase-protected key is a distinct, noisier activity from generating or fingerprinting one — get explicit sign-off before running it through a cracker.

KEEP EXPLORING

View the whole phase →