OpenSSH Public Key Fingerprint

Of the three SSH nodes in this pack, this is the one I'd actually reach for. Display name OpenSSH Public Key Fingerprint, category ARG Toolkit/Cryptography/Modern/Asymmetric. Feed it a public key, get the digest that identifies it.

Why it matters more than the loaders: a fingerprint is the short, comparable, safe-to-say-out-loud answer to "which key is this?" A key you were handed in a puzzle, a key posted in a clue, a key sitting on a server - you compare fingerprints, not 500 characters of base64. This node lets you do that comparison without leaving the graph.

Inputs and output

Two inputs, both required.

keyfile (BYTESLIKE) - the public key, same one-line OpenSSH format as everywhere else in this pack. It's a socket with no widget, so it comes from a multiline string through Bytes-like Object Encode with encoding UTF-8.

hash_algorithm (enum: MD5, SHA-1, SHA-256; default SHA-256) - which hash to identify the key with. Leave it on SHA-256. That's what modern ssh-keygen prints by default, and it's what any current writeup, server banner or challenge will quote. The other two exist to match old material: SHA-1 for pre-6.8 OpenSSH output and 2010s forum posts, MD5 for genuinely ancient puzzles. Unless you're matching a legacy artifact, they're archaeology.

fingerprint (BYTESLIKE) - the raw digest. 32 bytes for SHA-256, 20 for SHA-1, 16 for MD5. Bytes, not text, and not the string anyone quoted at you. That distinction is the whole gotcha.

How it works

The node parses the public key, then calls cryptography's ssh_key_fingerprint() with the hash you picked. That function hashes the SSH wire blob - the key type string followed by the key's encoded public data - which is precisely the construction OpenSSH uses. So the bytes coming out of this node are the same digest OpenSSH computes. Only the presentation differs: OpenSSH base64-encodes that digest and prefixes it, giving you SHA256:qRxTn8...; this node hands you the bare digest.

That's easy to fix in-graph. Wire fingerprint into the pack's Bytes-like Object Decode node with encoding Base64, and you get a STRING holding exactly the part that comes after the SHA256: prefix:

Bytes-like Object Encode (UTF-8, your .pub line)  →  SSHPublicKeyFingerprint (SHA-256)  →  Bytes-like Object Decode (Base64)  →  "SHA256:" + ...

Now it's directly comparable to what you get from the terminal:

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh-keygen -l -E sha256 -f id_ed25519.pub
ssh-keygen -l -E md5 -f id_ed25519.pub

One quirk if you go the MD5 route: the Hexadecimal decode mode gives lowercase hex with no separators, while OpenSSH prints MD5:aa:bb:cc:... with colons. You'll be eyeballing that one.

The dropdown matches what the library actually accepts - cryptography rejects any hash other than these three here - so you can't trip a "must be one of" error from the UI.

Install

Manager: search ComfyUI ARG Toolkit. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/AzelusLightvale/ComfyUI-ARG-Toolkit

Same caveat as the rest of the pack: requirements.txt is a uv-compiled lockfile that pins torch==2.14.0 and friends, and installing it wholesale over a working ComfyUI environment is how people end up with a broken torch install. The pack's headline deps are cryptography, secretpy, stegano, reedsolo and invisible-watermark; the SSH nodes only need cryptography. Python >=3.12 per pyproject.toml.

Where people get burned

"The fingerprint doesn't match anything." It's raw bytes. Nine times out of ten this is someone comparing the node's output to SHA256:... text from ssh-keygen -lf and wondering why nothing lines up. Base64 it with the decode node and they match exactly.

AttributeError: module 'cryptography.hazmat.primitives.serialization' has no attribute 'ssh_key_fingerprint'. Your environment has an old cryptography. Check and fix:

python -m pip show cryptography
python -m pip install -U cryptography

It won't parse the key. One line, first field a key type; a wrapped .pub fails before any hashing happens. A private key block pasted here fails outright - this node wants the public half, so run ssh-keygen -y -f id_ed25519 > id_ed25519.pub first if that's all you have.

Hardware-backed keys. [email protected] public keys (YubiKey-style) are the one family the fingerprint path in cryptography doesn't implement end to end, so you may get a raw Python exception instead of a digest. For those, ssh-keygen -lf on the .pub file is your answer, and it's a rare enough case that it isn't worth fighting.

And the trap that isn't a bug: whatever keyfile is fed by a string node also lives in your workflow JSON. Public keys are fine to share; swap the input for something secret and sharing the workflow shares that too.