4 ms·

Hi Tom - I don't know if you've already written about this elsewhere, but what would be some sane defaults for SSH? Do you think using key-based auth and disab

by akulbe 4y ago

Hi Tom - I don't know if you've already written about this elsewhere, but what would be some sane defaults for SSH? Do you think using key-based auth and disabling password authentication is enough? or are there other things you would recommend? OT - nice Fibonacci in your profile :D

antihero 4y ago
I’ve always used this: https://www.sshaudit.com/hardening_guides.html https://www.sshaudit.com/hardening_guides.html If there’s something better please correct me!
- akulbe 4y ago
  I wasn't familiar with this. I find it interesting that one of the suggestions is to disable the ECDSA host key. I thought ECDSA was one of the "good" algorithms?
  - EnigmaCurry 4y ago
    Its suspected from the snowden docs that this is one of the ones intentionally weakened by NIST. Here's the long answer: https://blog.cr.yp.to/20140323-ecdsa.html https://blog.cr.yp.to/20140323-ecdsa.html
    - tptacek 4y ago
      Nobody serious thinks the P-curves, which is what we're talking about, were weakened by NIST. I don't think anybody at all thinks the DSA algorithm was "intentionally weakened", but lots of people, reasonably, believe it was incompetently designed. Ed2519 has the virtue of both a better curve and a better signing algorithm, which is why it's used in preference to ECDSA. If you're using 25519, don't bother keeping the rest of the algorithms enabled. I think these hardening guides are mostly pretty silly too, for whatever that's worth. The important thing is making sure nobody can log into anything with a password. The rest is just liturgical.
  - youainti 4y ago
    I think it is the issue where ecdsa is a NIST standard that was based on an elliptic curve provided by the NSA. As the NSA has been known to suggest poor cryptography primitives in the past, many groups recommend ed25519 (same process, different and more trusted curve generation process) Take a look at the "concerns" section of the wiki page. https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm?wprov=sfla1 https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signatu...
- pferde 4y ago
  Wow, that's terrible. Imperative instead of declarative, and does not explain the reasons. Perfect for cargo-culting your way to disaster.
  - amelius 4y ago
    Also, why isn't hardened ssh the default? Is this breaking too many things for the user?
    - antihero 4y ago
      Compatibility basically.
  - antihero 4y ago
    Would you recommend a better guide? Is the config suggested by it bad? Not everyone has the skill/time to deeply understand everything immediately, and having a saner starting point is a good thing.
egberts1 4y ago
while it is not the best, I do regularly code audit OpenSSH. For sane default, you can generate your working but sane ssh_config and sshd_config based on my inner code knowledge and network security and as an IDS/IPS architect. Each and every known OpenSSL (v8.4; v9.0 is underway) settings in the config files have annotations and details and many have additional links detailing why. I also note where each and every config settings are found in the source code by nesting, what protocol state, control state, authentication stage, and lockings (makes code review so much easier for me) also in its comment section of each config setting. Even has a bash script to let you create these config files (defaults to your subdirectory for pretesting, but can also as an option update /etc/ssh, which I confidently do) into something that would pass an SSH audit for ssh-audit (I’m a contributor), CISecurity and often better. Also these scripts generates a script containing proper file permission settings based on top generic Linux File System variants (basic variants like APT, pacman, Portage, DNF/RPM) ). I also offer SSH bastion setup (adjacent to my URL given below) as well. I also enjoy using certificate-by-user as an authentication mechanism for maximum ease of sysadmin use when it comes to emergency mass-blocking or occasional employee departures. https://github.com/egberts/easy-admin/tree/b74765baa450593bea7e4914c3f024abadb2fda5/490-net-ssh https://github.com/egberts/easy-admin/tree/b74765baa450593be...

by akulbe 4y ago

antihero 4y ago

I’ve always used this: https://www.sshaudit.com/hardening_guides.html https://www.sshaudit.com/hardening_guides.html If there’s something better please correct me!

akulbe 4y ago
I wasn't familiar with this. I find it interesting that one of the suggestions is to disable the ECDSA host key. I thought ECDSA was one of the "good" algorithms?
- EnigmaCurry 4y ago
  Its suspected from the snowden docs that this is one of the ones intentionally weakened by NIST. Here's the long answer: https://blog.cr.yp.to/20140323-ecdsa.html https://blog.cr.yp.to/20140323-ecdsa.html
  - tptacek 4y ago
    Nobody serious thinks the P-curves, which is what we're talking about, were weakened by NIST. I don't think anybody at all thinks the DSA algorithm was "intentionally weakened", but lots of people, reasonably, believe it was incompetently designed. Ed2519 has the virtue of both a better curve and a better signing algorithm, which is why it's used in preference to ECDSA. If you're using 25519, don't bother keeping the rest of the algorithms enabled. I think these hardening guides are mostly pretty silly too, for whatever that's worth. The important thing is making sure nobody can log into anything with a password. The rest is just liturgical.
- youainti 4y ago
  I think it is the issue where ecdsa is a NIST standard that was based on an elliptic curve provided by the NSA. As the NSA has been known to suggest poor cryptography primitives in the past, many groups recommend ed25519 (same process, different and more trusted curve generation process) Take a look at the "concerns" section of the wiki page. https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm?wprov=sfla1 https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signatu...
pferde 4y ago
Wow, that's terrible. Imperative instead of declarative, and does not explain the reasons. Perfect for cargo-culting your way to disaster.
- amelius 4y ago
  Also, why isn't hardened ssh the default? Is this breaking too many things for the user?
  - antihero 4y ago
    Compatibility basically.
- antihero 4y ago
  Would you recommend a better guide? Is the config suggested by it bad? Not everyone has the skill/time to deeply understand everything immediately, and having a saner starting point is a good thing.

egberts1 4y ago

while it is not the best, I do regularly code audit OpenSSH. For sane default, you can generate your working but sane ssh_config and sshd_config based on my inner code knowledge and network security and as an IDS/IPS architect. Each and every known OpenSSL (v8.4; v9.0 is underway) settings in the config files have annotations and details and many have additional links detailing why. I also note where each and every config settings are found in the source code by nesting, what protocol state, control state, authentication stage, and lockings (makes code review so much easier for me) also in its comment section of each config setting. Even has a bash script to let you create these config files (defaults to your subdirectory for pretesting, but can also as an option update /etc/ssh, which I confidently do) into something that would pass an SSH audit for ssh-audit (I’m a contributor), CISecurity and often better. Also these scripts generates a script containing proper file permission settings based on top generic Linux File System variants (basic variants like APT, pacman, Portage, DNF/RPM) ). I also offer SSH bastion setup (adjacent to my URL given below) as well. I also enjoy using certificate-by-user as an authentication mechanism for maximum ease of sysadmin use when it comes to emergency mass-blocking or occasional employee departures. https://github.com/egberts/easy-admin/tree/b74765baa450593bea7e4914c3f024abadb2fda5/490-net-ssh https://github.com/egberts/easy-admin/tree/b74765baa450593be...