-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guidelines for ssh #9
Comments
New version (already implemented in develop branch) will include "recommendations", based on detected sshd version and "best effort". Although, take into account, that some issues can't be resolved without upgrading to newer version. If the output shows some warnings, it should also show description of those warnings. Care to elaborate with specific example? Otherwise, I can't really comment. But basically "my guideline" is to remove all failures and warnings, so that output is only "green". Other than that, there are also other steps to harden SSHd configuration, like, generating Diffie-Hellman with higher bits, allowing only public-key authentication, etc. There are several of articles about that. |
This software helps to adjust |
for example my configuration is now :
and the ssh-audit program still say that I have the key : I've just try your development version. It's look great. |
Yes, sorry, forgot about |
Great I have now only warning. Second question. For weak ciphers like ecdsa, do there are a way to generate better cipher instead of remove the algorithm ? |
For the second question, - short answer is "no". All one could add, one can see in "recommendations" section. Longer answer - ciphers are hard-coded into source of particular sshd software. There might be a reason why all of them are not available, e.g., disabled in compile-time or because of some missing crypto library. But the only way to "add" ciphers which aren't available by default, is to patch the source code, basically, writing the code yourself and recompiling the software. For first question, - that's why I haven't linked any articles, because they are and get outdated (and are not controlled by me). And that's why I wrote this tool - to have up-to-date information. Also, for example, I and other people in their articles on the subject disagree with Your mentioned Mozilla guidelines. They are a generalized, a good starting point, but not as strict as one might want. And they don't explain the reasons behind their settings well. I've jet to see a "perfect" article in this field. Some come very, very close, but none of them combine everything. Currently, one can grab bits from one article and bits from other article to get the full picture. But I get why that is. Writing a "small tutorial" will soon become a "large document", if one wants to cover everything. For example, in this thread, we are talking about OpenSSH and it's configuration. What about other sshd servers? They have different options how to configure them. Which version should such article cover? If it covers latest version, then some tuning options could be missing or completely different for people who can't upgrade to latest version. Also, there are differences depending on which OS the sshd server is running. For example, some security features for OpenSSH might be only available only on OpenBSD (as that's the base OS where it is being developed), which has been the case several times. Of course, other OS'es play catch-up. Then there are different thoughts - should one use public key authentication or certificates? I could go on... Having said that, I agree that some better documentation or small article could be beneficial to newcomers, as currently this tool is mostly useful for people, who know what the output means and what to do about it, i.e., server administrators, pen-testers, etc Therefore, I should probably write such article, but I think this should go into wiki or as separate document, because it would overwhelm the readme. And to keep it "small", I should probably target latest OpenSSH version and it's specific configuration. |
Perfect, Thank you for all yours explanations. |
I think simply including in the readme a short section on how to read the output would solve this issue. |
Hi Arthepsy, key exchange algorithms I kinda understand the reference to WARN & INFO... but what is the reference to FAIL? Does that indicate the functionality has been removed/disabled and isn't available for the ssh audit - or is it the otherway around and they have failed the audit and need to be resolved/investigated asap. Any other quick tips on using this would be greatly appreciated. I did go looking for a WIKI... but I couldn't find anything. |
[info] --> good, you can keep this conf |
Hey Azlux, |
As of today (and last updated on 27-Oct-17), the Mozilla Security Guidelines continue to list the host key "ssh_host_ecdsa_key" and "ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256" among the recommended KexAlgorithms for the Modern Config (OpenSSH 6.7+). |
I can attest to the problem of maintaining a document to keep SSH current and do advocate the I maintain several bash scripts that produces various SSH setups and it is becoming easier now as times goes by, but I still refer to SSH-AUDIT to quickly boil down what is out there (as opposed to what I (and my scripts) need to push out there). |
Thank for your work.
But after this audit, what are your guidelines for sshd_config ?
I've seen this one : https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern_.28OpenSSH_6.7.2B.29 but your audit still show some warning.
Azlux
The text was updated successfully, but these errors were encountered: