Community Feedback: What do you use ssh_scan for?

[claudijd]

One of the reasons we created ssh_scan was to help administrators and security professionals get more visibility to their running SSH configurations and see if that would help move the needle for them.

In this issue, we'd love to hear some feedback from the user community of ssh_scan to see what creative uses you are using it for (pentesting? compliance? CI/CD? etc?).

We'd also like to point out that this is the perfect place to tell us what works and doesn't so we can make sure you don't loose important features and that we're continuing to bring new and useful features to bear.

[exploide]

While I configured a SSH server some time ago, I had my first contact with ssh_scan. I wanted to check if my config file was actually used and if the service behaves indeed as specified. So it was a check tool during administration for me.

Meanwhile, I use ssh_scan for pentests and audits to check customer's SSH config and make recommendations based on the results afterwards. It fits my needs and has a few advantages over the ssh-audit tool. Most importantly ssh_scan is (somewhat) actively maintained and its output is machine readable (we try to automate stuff).

However, there are also a few things I would put on a whishlist if you ask 😛

• Enumerate offered host keys (e.g. DSA, RSA, ECDSA, ED25519) along with their key sizes
• More versatile policy engine, especially to express "certain algorithms are nice to have but not strongly required"; basically Redesign the policy engine #61
• Maybe check for existing SSHFP DNS record and if it matches what the SSH service delivers
• Optional human readable output (either by allowing to switch between JSON and plain or by replacing JSON with YAML as a compromise)

[claudijd]

@exploide that's excellent feedback, thank you! I'm glad the decisions to roll with JSON has helped you automate your work. I believe the offered host keys should be fixed in the 0.0.37 (it was sadly broken and I hadn't noticed for a while), but I think it's just for DSA/RSA atm, but could be extended with a little work. I'm glad the policy engine stuff is on your radar, it's something we've been dabbling with for a while, and we've had some good work there, just not landed yet. I wasn't aware of SSHFP DNS stuff, will check into that. As for the human readable output, I think at one point in the projects history we did have other formats, but I should be pretty trivial to make an override to turn the JSON into YAML, I may tackle that quickly since it's so easy, but probably after I get the bug fixes from the recent release out. Thanks again for sharing, it's so good to hear that it's helpful to people and it's making a difference in how they improve security.

[claudijd]

@exploide I added YAML support in a recent PR, have a peek and let me know if that serves the need as a short-term compromise (#480)

[claudijd]

@exploide I also released new YAML support in 0.0.38, so please give it a spin and let me know what you think.

[exploide]

@claudijd Thanks for your reply and the steps forward. Your response time is awesome!

I like the new YAML output. It's clean and has less distracting syntax 👍 (to be honest, JSON wasn't too bad either, it's prettyfied and all...)

Regarding host keys: Do you mean the output in the fingerprints section or is there something else I miss? This is already good information but you are right, I only see RSA (and probably DSA if it were available). Support for EC schemes would be great for the future. But back to RSA/DSA. For those two, showing the key length would be rather important. A 512 bit RSA host key for example is a bit lousy.

Thanks for building this tool!