SSH hardening guide bonus edition: Disable password login if you can, leave the algorithm settings as they are and use an up to date version of OpenSSH.<p>OpenSSH already agressively deprecates algorithms that are problematic. None of the algorithms enabled by default has any known security issue. But your manual tweaks from a random document you read on the Internet may enable an algorithm that we may later learn to be problematic.
Is it really necessary to disable an E521 ECDSA host key? By all means, replace a P256 host key with E521, but are E521 keys truly weak to justify removal?<p>E521 is listed as safe on DJB's main evaluation site:<p><a href="https://safecurves.cr.yp.to/" rel="nofollow">https://safecurves.cr.yp.to/</a><p>More specific DJB commentary: "To be fair I should mention that there's one standard NIST curve using a nice prime, namely 2^521 – 1; but the sheer size of this prime makes it much slower than NIST P-256."<p><a href="http://blog.cr.yp.to/20140323-ecdsa.html" rel="nofollow">http://blog.cr.yp.to/20140323-ecdsa.html</a><p>I believe that OpenSSH is using the E521 provided by OpenSSL (as seen on Red Hat 7):<p><pre><code> $ openssl ecparam -list_curves
secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
</code></pre>
These appear to have been contributed by Sun Microsystems, and were designed to avoid patent infringement.<p><a href="https://security.stackexchange.com/questions/3519/can-ecc-be-used-without-infringing-on-patents" rel="nofollow">https://security.stackexchange.com/questions/3519/can-ecc-be...</a>
Not everyone knows that you can use MFA with SSH. I’ve successfully used Google authenticator via PAM[1] and YubiKey[2].<p>You can also setup SSH certificate authorities instead of using self-signed ones [3]<p>[1] <a href="https://wiki.archlinux.org/title/Google_Authenticator" rel="nofollow">https://wiki.archlinux.org/title/Google_Authenticator</a><p>[2] <a href="https://developers.yubico.com/SSH/" rel="nofollow">https://developers.yubico.com/SSH/</a><p>[3] <a href="https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-certificate-authority/" rel="nofollow">https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-cer...</a>
The first thing i do on a new remote box is to move SSH to another non-standard port other than 22. I use the same port for every remote boxes I have. Then add that port into `.ssh/config` on local box.<p>Second is to disable root login.<p>Third is to copy my private key over and disable password login.<p>3 essential steps to secure SSH.
Relevant: If your SSH server is public, you can give its address to <a href="https://sshcheck.com/" rel="nofollow">https://sshcheck.com/</a> and it will report any weak spots in your config.
When using the SSH protocol for running automated remote commands you can improve security using forced command[1] within your authorized_keys file.<p>[1] <a href="https://ctrlnotes.com/restrict-a-user-to-ssh-forced-command/#" rel="nofollow">https://ctrlnotes.com/restrict-a-user-to-ssh-forced-command/...</a>
NanoBSD?<p>I feel like an important part of "hardening" a server is to remove/disable unused services. Does anyone know if NanoBSD is actively worked-on by the FreeBSD team and/or still in use? For those note aware, NanoBSD is an official build from FreeBSD team that allows you to compile a slimmed down FreeBSD build that is read-only yet can run any/all FreeBSD software.<p>I can find very little about NanoBSD other than a handful of posts from 10 years ago. It seems like a great foundation for hardening a server.<p><a href="https://docs.freebsd.org/en/articles/nanobsd/" rel="nofollow">https://docs.freebsd.org/en/articles/nanobsd/</a>
I like reading tutorials on this subject. One of my favorites, albeit six years old, is <a href="https://stribika.github.io/2015/01/04/secure-secure-shell.html" rel="nofollow">https://stribika.github.io/2015/01/04/secure-secure-shell.ht...</a>
I always heard that FreeBSD has unparalleled networking<p>Does it mean that it'd be worth picking FreeBSD over Linux for my C# crud app if it had to handle a lot of requests/sec? (let's ignore db for the moment)