Letting openssl tools understand openssh keys?

[Dan Mahoney]

Hey there all,

I have a simple question.  Would it be possible to have the openssl asn1parse tools and the like be able to show the details in openssh private key formats?  There are data blocks in the private key (including an unencrypted copy of the public key -- which I believe s sent during ssh session setup), and unless you know this and can print it out, it's non-obvious.

This might also be useful in an audit scenario, where you wanted to look to ensure that users had no keys with no password set.

The only write-up I've found is here: https://coolaj86.com/articles/the-openssh-private-key-format/

It's ASN-1 encoded with base64, but the tools included with openssl don't properly decode them, and openssh themselves have no such tools to do so.  It makes sense that if there's one "can-opener" that can handle these, it should be forgiving of this weird format.

-Dan

(Apologies I am not using my normal email addresses, google groups seems to really want a gmail address, and I'm not letting google have one from my own domain)

[Alan Buxey]

Trying to do this inline or do you have access to the keys?  If doing an audit and you have key access then there is an OpenSSH tool that can help:

ssh-keygen -y -P "" -f "$path_to_keyfile"

If there's a password then it'll error. If not then it'll return no error

There are a few OpenSSH ASN.1 formats, the legacy and the new secure format etc there are also other ways of examining the key files to check whether there is an encrypted element, that varies depending on type of key

Regards

Alan

[Dan Mahoney]

I listed that as one *possible* use, but my point was more that there is presently no tool that can digest and parse-to-readable this blob of base64-encoded-pem-with-a-\-\-\-\-BEGIN\-FOO that looks like every other blob of base64-encoded-pem-with-a-\-\-\-\-BEGIN\-FOO that openssl asn1 parse *can* understand, and rather than getting errors, it would be useful to get at least a dump of the data.

I'm talking about the "new secure format", not the legacy one which is defined by an RFC, the one that I linked to an article describing the format of.

-Dan