update ssh2john to support all algs from openssh

[noraj]

It's not about John itself but one of the companion tool provided with it: ssh2john.

https://github.com/openwall/john/blob/bleeding-jumbo/run/ssh2john.py

ssh2john supports a very limited set of algorithms

john/run/ssh2john.py

Lines 41 to 45 in 173b562

	'AES-128-CBC': {'cipher': AES, 'keysize': 16, 'blocksize': 16, 'mode': "AES.MODE_CBC"},
	'DES-EDE3-CBC': {'cipher': DES3, 'keysize': 24, 'blocksize': 8, 'mode': "DES3.MODE_CBC"},
	'AES-256-CBC': {'cipher': AES_256, 'keysize': 32, 'blocksize': 16, 'mode': "AES.MODE_CBC"},
	'AES-192-CBC': {'cipher': AES, 'keysize': 24, 'blocksize': 16, 'mode': "AES.MODE_CBC"},
	'AES-256-CTR': {'cipher': AES_256, 'keysize': 32, 'blocksize': 16, 'mode': "AES.MODE_CTR"},

Whereas most of the algs supported by openssh are not supported by ssh2john.

The following script can be used to generate a key for each alg and try to ssh2john it for each. You'll see a lot are not supported even if they are supported by John.

algs=("3des-cbc" "aes128-cbc" "aes128-ctr" "[email protected]" "aes192-cbc" "aes192-ctr" "aes256-cbc" "aes256-ctr" "[email protected]" "[email protected]")
for alg in "${algs[@]}"
do
    ssh-keygen -o -N test12345 -t ed25519 -Z $alg -f test_$alg 1>/dev/null
    ssh2john test_$alg > hash_$alg.txt
done

For example, EC with AES 128 looks supported but John but not by ssh2john

john/src/ssh_fmt_plug.c

Lines 375 to 384 in 173b562

	} else if (cur_salt->cipher == 3) { // EC keys with AES-128
	unsigned char key[16];
	AES_KEY akey;
	unsigned char iv[16];
	memcpy(iv, cur_salt->salt, 16);
	generate_key_bytes(16, (unsigned char*)password, key);
	AES_set_decrypt_key(key, 128, &akey);
	// full decrypt
	AES_cbc_encrypt(cur_salt->ct, out, cur_salt->ctl, &akey, iv, AES_DECRYPT);

➜ ssh-keygen -o -N test12345 -t ecdsa -Z aes128-cbc -f test_ec+128
Generating public/private ecdsa key pair.
Your identification has been saved in test_ec+128
Your public key has been saved in test_ec+128.pub
The key fingerprint is:
SHA256:XIRSO83q23eYVERJDn7lBJ74bRm4tVWVw8LJcKL53lA noraj@norarch
The key's randomart image is:
+---[ECDSA 256]---+
|       ....o=+*oB|
|      . .=o.oX+O.|
|       .oo+ oE*o+|
|       . +. .o+.=|
|        S  o o.oo|
|       .  . +  . |
|        .  o +   |
|         o  + .  |
|        . .. .   |
+----[SHA256]-----+

➜ ssh2john test_ec+128
Traceback (most recent call last):
  File "/usr/bin/ssh2john", line 225, in <module>
    read_private_key(filename)
  File "/usr/bin/ssh2john", line 157, in read_private_key
    raise Exception('Unknown encryption type')
Exception: Unknown encryption type

ssh2hon from John the Ripper 1.9.0-jumbo-1+bleeding-173b5629e8 2024-01-18 00:08:42 +0100 MPI + OMP [linux-gnu 64-bit x86_64 AVX AC]

[solardiz]

Thank you @noraj! Is this something you'd like to work on? We'd appreciate a pull request. (Assuming that your analysis here is correct. I did not verify.)

[noraj]

@solardiz What would you expect? ssh2john supporting all possibilities supported by john only or all possibilities supported by ssh-keygen?

Also, in the light of #4564 and #5255 and many others, wouldn't it be good to separate all the tools from /run in a different repository? It would allow faster release for those tools than JtR slow lifecycle. Also both code are completely independent.

I don't think I'm able to PR, I dont't understand what combination of key size, key type, encryption type, etc. would lead to a hash type and why. Having blocksize in the dict seems useless. It sounds like a partial re-write of the tool would be beneficial. I'm also extremely bad at C so it's hard for me to understand what exactly john is supporting.

[solardiz]

What would you expect? ssh2john supporting all possibilities supported by john only or all possibilities supported by ssh-keygen?

Perhaps first make ssh2john support everything in john. As to the rest, it can also be added - with a separate commit/PR, and perhaps printing a warning that it "may not yet be supported by john" or such.

wouldn't it be good to separate all the tools from /run in a different repository?

This was suggested and I thought of it, and my current opinion is that no - it's better to keep them in here. We do need to release more often and to clean things up, but a separate repo and having to make separate releases isn't the way there.

It sounds like a partial re-write of the tool would be beneficial.

I agree. Perhaps we could get rid of our own numeric cipher types and include the info in "hashes" with less re-processing. However, I have no idea who would do that and when. So adding support for what's missing first is reasonable.