Guidelines for ssh

[azlux]

Thank for your work. But after this audit, what are your guidelines for sshdconfig ? 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

[arthepsy]

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.

[arthepsy]

This software helps to adjust KexAlgorithms, Ciphers and MACs section in Your sshd_config. If You copy/pasted configuration from Mozilla guidelines, then just adjust it afterwards, according to ssh-audit output. Current version (1.5.0) output will show what to remove (warnings, failures), but new version (will be released next week) will have different section, called "recommendations", which will also show what to append to configuration.

[azlux]

for example my configuration is now :

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

and the ssh-audit program still say that I have the key : "(key) ecdsa-sha2-nistp256 -- [fail] using weak elliptic curves " So I suppose not all the keys are into the sshd_config file.

I've just try your development version. It's look great. Good work !

[arthepsy]

Yes, sorry, forgot about HostKey and HostKeyAlgorithms settings in sshd_config. To get rid of this warning, You could remove HostKey /etc/ssh/ssh_host_ecdsa_key line or adjust HostKeyAlgorithms. Can You verify that this helps?

[azlux]

Great I have now only warning. So like I said, may be a small tutorial or some links for a better configuration will be usefull into your readme. The security change so fast, lot of popular documentations are outdated.

Second question. For weak ciphers like ecdsa, do there are a way to generate better cipher instead of remove the algorithm ?

[arthepsy]

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.

[azlux]

Perfect, Thank you for all yours explanations. I let you close this issue if you want or keep it open if you think it's help people to find those explanations. I'll keep an eye on this project.

[jsumners]

I think simply including in the readme a short section on how to read the output would solve this issue.

[kingkennyb]

Hi Arthepsy, I am new to this and have just been given a task to check some ssh vulnerabilities on a few servers. For example I am seeing the following output regarding diffie-hellman:

key exchange algorithms [warn] using custom size modulus (possibly weak) [info] available since OpenSSH 4.4 [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm [warn] using weak hashing algorithm [info] available since OpenSSH 2.3.0 [warn] using weak hashing algorithm [info] available since OpenSSH 3.9, Dropbear SSH 0.53 [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm [fail] disabled (in client) since OpenSSH 7.0, logjam attack

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. Thanks and Kind Regards, K.

[azlux]

[info] --> good, you can keep this conf [warn] --> still good, but not the best algorithm, it's can be better [fail] --> you have security problem, know attacks will work.

[kingkennyb]

Hey Azlux, Thanks for the update. Very much appreciated. :)

[jchevali]

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+). ssh-audit, however, continues to issue red warnings for the KexAlgorithms above, including for the stronger and strongest ones of 384 and 521 bits. Could you, if the Mozilla recommendations are wrong, tell us unequivocally that you believe they are wrong, i.e., make a strong statement. Or if they're not wrong, and ssh-audit would need updating (and I notice this ticket is still open), give us some indication as to by which date this discrepancy will be addressed in this repository?

[egberts]

I can attest to the problem of maintaining a document to keep SSH current and do advocate the ssh-audit approach as a form of auditable and verification and validation.

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).

https://github.com/egberts/easy-admin/tree/main/490-net-ssh