ssh2john and john unable to brute-force password #4069
Comments
|
What version of OpenSSH did you use to create it, and with which options? Can you actually use it? |
|
This was generated by OpenSSH 7.9 and I simply ran |
|
I need to test that. Ideally we'd have @kholia suffering a JtR relapse and create a couple of Good Stuff[tm] PR's a day for a (long) period again... |
|
See the following link. I tested it out using the Kali package install and also attempted building from source and got the same issues here: https://security.stackexchange.com/questions/224109/how-do-i-crack-an-id-rsa-encrypted-private-key-with-john-the-ripper |
|
Confirmed, I can reproduce |
When can we expect a bug fix? |
|
Not sure if this'll help, but I came across this bug today, and running the command as: But running the command as: |
|
@tuv7041 thank you, yes, this is of help! However, the order of parameters is definitely not the issue so what really happened there, I'm sure, is JtR would sometimes crack it. If you try deleting |
In short, you can't (unless you fix the bug). This is free (as in free beer), open source (as in you know what's in the beer) software, developed by volunteers. We are severely short of developers and I have SO many issues to take care of. That said, this particular issue is one that I will look into sooner or later unless someone else does and finds the culprit. |
Of course, the order of parameters is not the issue, but the provided example suggests that the first time another instance of JtR was somehow still running, preventing the new session from being started - a local issue unrelated to ssh "hash" support. So I don't see this example helping us at all - it'd need to be repeated without triggering that unrelated issue.
|
|
Right, I didn't spot that. Also, the OP hash is Bcrypt/AES with 16 iterations. I shouldn't assume that all people that post here know what they're doing 😢 |
This worked for me, thanks! |
|
With |
|
When you say When you say |
|
Some ssh keys encrypted by ssh-keygen are using aes-256-ctr, instead of the previous aes-256-cbc. Here's an example generated with openssh 8.2: OP's key was also using aes256-ctr, but ssh2john and john both assume aes256-cbc. I haven't thoroughly checked which versions of ssh-keygen encrypt keys with CTR, but on Arch Linux, it looks like the switch happened sometime between openssh 7.4 (2016-12) and 7.6 (2017-10). |
Yes, This directly leads to "No password hashes loaded (see FAQ)" error. |
Add support for ssh private key passphrase encrypted using `aes256-ctr`. Fixes openwall#4069 Test ```bash $ ssh-keygen -t rsa -b 4096 -f id_rsa-aes256-cbc -Z aes256-cbc -N TestPassword $ ssh-keygen -t rsa -b 4096 -f id_rsa-aes256-ctr -Z aes256-ctr -N TestPassword $ echo TestPassword >passwords.lst $ ./ssh2john.py id_rsa-aes256-cbc id_rsa-aes256-ctr >id_rsa.hash $ ./john --wordlist=passwords.lst id_rsa.hash ... TestPassword (id_rsa-aes256-ctr) TestPassword (id_rsa-aes256-cbc) ```
Add support for ssh private key passphrase encrypted using `aes256-ctr`. Fixes openwall#4069 Test ```bash $ ssh-keygen -t rsa -b 4096 -f id_rsa-aes256-cbc -Z aes256-cbc -N TestPassword $ ssh-keygen -t rsa -b 4096 -f id_rsa-aes256-ctr -Z aes256-ctr -N TestPassword $ echo TestPassword >passwords.lst $ ./ssh2john.py id_rsa-aes256-cbc id_rsa-aes256-ctr >id_rsa.hash $ ./john --wordlist=passwords.lst id_rsa.hash ... TestPassword (id_rsa-aes256-ctr) TestPassword (id_rsa-aes256-cbc) ```
Add support for ssh new-style private keys encrypted using `aes256-ctr`. Fixes openwall#4069 Test ```bash $ ssh-keygen -t rsa -b 4096 -f id_rsa-aes256-cbc -Z aes256-cbc -N TestPassword $ ssh-keygen -t rsa -b 4096 -f id_rsa-aes256-ctr -Z aes256-ctr -N TestPassword $ echo TestPassword >passwords.lst $ ./ssh2john.py id_rsa-aes256-cbc id_rsa-aes256-ctr >id_rsa.hash $ ./john --wordlist=passwords.lst id_rsa.hash ... TestPassword (id_rsa-aes256-ctr) TestPassword (id_rsa-aes256-cbc) ```
The default cipher has been changed since 7.6: openssh/openssh-portable@0f34553 |
Add support for ssh new-style private keys encrypted using `aes256-ctr`. Fixes openwall#4069 Test ```bash $ ssh-keygen -t rsa -b 4096 -f id_rsa-aes256-cbc -Z aes256-cbc -N TestPassword $ ssh-keygen -t rsa -b 4096 -f id_rsa-aes256-ctr -Z aes256-ctr -N TestPassword $ echo TestPassword >passwords.lst $ ./ssh2john.py id_rsa-aes256-cbc id_rsa-aes256-ctr >id_rsa.hash $ ./john --wordlist=passwords.lst id_rsa.hash ... TestPassword (id_rsa-aes256-ctr) TestPassword (id_rsa-aes256-cbc) ```
Add support for ssh new-style private keys encrypted using `aes256-ctr`. Fixes #4069 Test ```bash $ ssh-keygen -t rsa -b 4096 -f id_rsa-aes256-cbc -Z aes256-cbc -N TestPassword $ ssh-keygen -t rsa -b 4096 -f id_rsa-aes256-ctr -Z aes256-ctr -N TestPassword $ echo TestPassword >passwords.lst $ ./ssh2john.py id_rsa-aes256-cbc id_rsa-aes256-ctr >id_rsa.hash $ ./john --wordlist=passwords.lst id_rsa.hash ... TestPassword (id_rsa-aes256-ctr) TestPassword (id_rsa-aes256-cbc) ```
|
I must say it is still here on up to date linux OS. Here are steps to reproduce: As seen nothing found... but when I force the cipher during a keygen as in the 51f7f3d , it works just fine: It's not normal that John can't find the key with a default cipher of ssh-keygen. |
|
@binarytrails Are you using our latest code? It sounds like you're not, but are instead using a For your own use, of course just use our latest code from this repo - not whatever came with the distro. We almost always recommend that for best experience, even in absence of bugs. |
|
Confirmed that this sample is processed properly with our latest code: BTW, we might want to add it to the john-samples repo - please feel free to send us a PR against that one. |
|
@binarytrails, I believe your attempt failed because |
|
@vkhromov No, @binarytrails was using the CPU format. (There were messages merely suggesting options to use OpenCL.) Explicit |
@vkhromov yes, I tried running with Here my two OSs versions that I used with the same results are latest Arch Linux and latest Kal Linux in a VM:
@solardiz You have a good point about the latest code. I will clone & compile your master here and report back.
Yes, I can make a PR after with my sample code using the default ssh-keygen key that currently fails. I saw you created the PR openwall/john-samples#1; Does it mean that the default ssh-keygen is using aes256-ctr? Thank you for the quick replies! 🐙 |
Please do. Thanks!
Not a PR yet, just an issue so that we don't forget.
That's my understanding per the comments above. |
|
@solardiz I just compiled the master on arch and same results: |
|
@binarytrails Did you also use our latest you're getting: This 6 vs. 2 difference suggests your input file to |
|
@solardiz great spotting! you're right. I did use the old ssh2john output so the problem was not in john but this script! Thank you! It makes my day. I will do the PR with this example later on. Cheers |
Steps to reproduce
I created the following private key with the password
123.id_rsa.txt
Converted it via
ssh2john.pyinto a john-compatible format.id_rsa_johnformat.txt
Tried to get the used password by using john, but it never found a valid solution. For example:
System configuration
Attach details about your OS and about JtR, including:
$ ./john --list=build-info.The text was updated successfully, but these errors were encountered: