node-sshpk

sshpk is a pure-JavaScript library for working with SSH public and private keys, key fingerprints, signatures, and X.509/OpenSSH certificates, without shelling out to ssh-keygen or linking against OpenSSL. It normalizes RSA, DSA, ECDSA (nistp256/384/521), and ED25519 keys behind a single Key/PrivateKey API, and can read and write between PEM (PKCS#1/PKCS#8), OpenSSH (legacy and post-6.5 openssh format), raw RFC 4253 wire format, PuTTY .ppk files, and DNSSEC key files.

Beyond parsing, sshpk exposes signing and verification objects that mirror Node’s built-in crypto.Sign/crypto.Verify API, Diffie-Hellman key exchange helpers, and fingerprint objects that support constant-time matching to avoid leaking timing information. Its certificate support covers both X.509 and OpenSSH certificate formats, including self-signed certificate generation, issuer/subject identity parsing (LDAP-style DNs), and key-usage purpose inspection — though it deliberately does not implement full CA chain-of-trust verification.

The library began life extracted out of node-http-signature and node-ssh-fingerprint at Joyent, and today underlies SSH-agent tooling (sshpk-agent) and HTTP request-signing libraries in the Node ecosystem. It ships CLI utilities (sshpk-conv, sshpk-sign, sshpk-verify) alongside the library for ad-hoc key inspection and conversion from the command line.

What You Get

• Unified Key/PrivateKey classes - one object model for RSA, DSA, ECDSA and ED25519 keys regardless of which format they were parsed from
• Format conversion - read and write PEM (PKCS#1/PKCS#8), OpenSSH, RFC 4253 wire format, PuTTY .ppk, and DNSSEC key files
• Fingerprint objects - compute and constant-time-match SSH- and SPKI-style fingerprints in MD5, SHA1, SHA256, SHA384 or SHA512
• Sign/verify helpers - createSign/createVerify wrappers with the same interface as Node’s native crypto.Sign/crypto.Verify
• Certificate support - parse and generate X.509 and OpenSSH certificates, including self-signed certs and key-usage purpose checks
• Bundled CLI tools - sshpk-conv, sshpk-sign and sshpk-verify for command-line key inspection and conversion

Common Use Cases

• Verifying SSH keys in Node tooling - a deployment or provisioning script parses an uploaded id_rsa.pub file and checks its type, size and fingerprint before trusting it
• HTTP request signing - libraries built on node-http-signature use sshpk’s PrivateKey#createSign/Key#createVerify to sign and verify authenticated API requests
• Converting keys between formats - a CI pipeline reads a PuTTY .ppk key and re-serializes it as OpenSSH format for use with a Linux build agent
• Matching keys against known fingerprints - an SSH-agent proxy (sshpk-agent) uses parseFingerprint().matches() to locate a specific key among several loaded in an agent
• Issuing self-signed certificates - a service generates a private key and a self-signed X.509/OpenSSH certificate for internal mutual-TLS-style authentication

Under The Hood

Architecture sshpk is organized as a thin lib/index.js facade over five core classes (Key, PrivateKey, Fingerprint, Signature, Certificate, Identity) that each delegate format-specific parsing to a lib/formats/ registry (pem, pkcs1, pkcs8, rfc4253, ssh, ssh-private, dnssec, putty, x509, x509-pem, openssh-cert, plus an auto format that probes the others). Key and PrivateKey normalize algorithm-specific key material into a common parts array keyed by algs.info, so downstream consumers (fingerprinting, signing, DH) never need to branch on key type themselves; PrivateKey#derive and the optional ed-compat module handle the ed25519/curve25519 conversion edge case. This format-registry-plus-normalized-model design means adding a new on-disk format is additive (a new lib/formats/*.js module) rather than requiring changes throughout the codebase, and a change to the core Key abstraction would ripple through every format module and the CLI tools uniformly.

Tech Stack The library targets Node >=0.10 and has no native bindings — cryptography is delegated entirely to Node’s built-in crypto module, with pure-JS supporting packages for algorithms Node itself doesn’t cover: jsbn and ecc-jsbn (big-integer/ECC math), tweetnacl (ED25519), bcrypt-pbkdf (OpenSSH private key encryption), asn1 (DER/BER parsing for PEM and X.509), and small utility deps (assert-plus, dashdash for CLI argument parsing, getpass, safer-buffer). Dev dependencies (tape, sinon, benchmark, temp) round out testing and micro-benchmarking. Build/CI is driven by a Makefile and Jenkinsfile rather than modern JS tooling (no bundler, no TypeScript).

Code Quality Tests use tape and live under test/, with dedicated files per format and feature area (pem.js, putty.js, dnssec.js, certs.js, fingerprint.js, signature.js, plus a test/assets fixture directory of real key files) — a substantial, format-by-format suite rather than a handful of smoke tests. Error handling is explicit and typed: lib/errors.js defines dedicated KeyParseError, InvalidAlgorithmError, FingerprintFormatError, CertificateParseError and KeyEncryptedError classes (via util.inherits) that carry structured metadata (e.g. innerErr, keyName, format) rather than throwing bare strings. Argument validation throughout uses assert-plus (assert.object, assert.arrayOfObject, etc.) at public API boundaries. There is no TypeScript, and no visible linter/formatter config, consistent with the library’s age and Joyent-era conventions; CI runs via a Jenkinsfile rather than GitHub Actions.

What Makes It Unique sshpk’s distinguishing technical choice is breadth of format coverage in pure JavaScript with zero shell-out or native-binding dependency: PEM, both flavors of OpenSSH, raw RFC 4253 wire format, PuTTY .ppk (including a truncated-file variant), and DNSSEC key files are all supported behind one normalized Key/PrivateKey model, and its Fingerprint#matches is explicitly implemented with double-hashing to avoid leaking timing side-channels — a security-conscious detail many simpler key-parsing libraries skip. Its certificate module also deliberately scopes itself to metadata extraction and self-signed cert generation rather than attempting (and getting wrong) full X.509 CA chain-of-trust verification, which the README calls out explicitly as out of scope.