12 ms·

FreeBSD SSH Hardening

164 points by rodrigo975 5y ago

tester756 5y ago
I always heard that FreeBSD has unparalleled networking 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)
- deleted 5y ago
  [deleted]
- kd913 5y ago
  I don't think it would be worthwhile. If you want better latency and throughput, you wouldn't be using the kernel network stack and instead be opting for some userspace networking stack like DPDK or onload. Depends obviously on what the bottlenecks of your application are, your NIC and the characteristics of your hardware as well.
  - crest 5y ago
    FreeBSD has netmap for fast userspace packet processing.
    - kd913 5y ago
      True, and the Linux kernel has zero-copy AF_XDP that enable memory to be shared with userspace. However, low-latency networking is a lot more than just simple kernel bypass. It's things like pinning cpu cores dedicated for networking, disabling C-states, epolling and being able to utilize bespoke firmware interfaces designed for smartnics. Also application protocol, ie using features like TCP checksum offload and TSO. Heck the application would also need to be adjusted for a low-latency environment via probably a custom JVM and doing things like reading data structures/variables to ensure they are in CPU cache. Frankly I would recommend trying openonload which at least is compatible with native Linux socket programming unlike DPDK.
  - almalkemqq 5y ago
    I loved the simple explanation :)
- toast0 5y ago
  As with all things, you would really need to benchmark the system, preferably with real load, both ways to know for sure. But that takes a lot of time, especially if you're going to put in the time to tweak both systems. People can do amazing stuff with enough time in both FreeBSD and Linux. I honestly think most server applications wouldn't be held back by either OS. You need your application to be really lightweight and focused before the OS makes a big difference, and even then, the differences only show if you're maxing out the hardware. I worked at WhatsApp, and enjoyed working with FreeBSD there, and clearly it worked for us. Linux in FB datacenters also worked, but the server components were a lot different so there was never an apples to apples comparison. I run FreeBSD on my personal servers because I enjoyed working with it at Yahoo and then WhatsApp; but my personal servers don't have any performance needs. Sure, the networking stuff is nice (and it was nice to work with in the kernel), but what I like most about FreeBSD is the lack of churn. I can look at old administrative recipies and all the commands still work. I can expect (and mostly get) that when I upgrade, everything will keep working, and maybe a little better; occassionally, a lot better.
  - waynesonfire 5y ago
    > but what I like most about FreeBSD is the lack of churn I agree completely. As I mature in this field this becomes an ever important characteristic of the technology I adopt. Erlang also shares this property.
    - toast0 5y ago
      I feel like Erlang churn is more acceptable because they're usually honest in naming. You get pg2 which does what pg did, but differntly. And now pg (which could have been pg3, but the old pg had been gone long enough to reclaim the name). Similar with phash2, although phash may live for much longer.
  - tiffanyh 5y ago
    Hi toast0 IIRC, I saw a presentation by someone (Rick?) where at your previous employer - you guys slimmed FreeBSD down to be unbelievably minimal such that only 2-3 total services ran on the entire server. Was that done for performance reason? Or for hardening reasons? If someone wanted to do that today with FreeBSD: would you recommend it and how would you go about doing it (NanoBSD)?
- adrian_b 5y ago
  There was a time when FreeBSD had much better networking performance than Linux, but that was many years ago. Now, on supported hardware, their performance should be similar. However, Linux has drivers for much more varied networking hardware. FreeBSD has very good support for Intel NIC's but some of the hardware from other vendors may happen to be not supported. FreeBSD has a few nicer kernel features for those who develop themselves a networking application, but more networking libraries useful for high performance applications are available for Linux, even if DPDK, which was mentioned in another reply, is available for both Linux and FreeBSD. So, while I am a very satisfied FreeBSD user, I would recommend to someone with less experience to use Linux, as there are more resources readily available. On the other hand, for someone who wants to learn more about the implementation of networking applications, it can be useful to also try FreeBSD, to understand more about alternative solutions.
- 0xdeadb00f 5y ago
  FreeBSD (and all BSDs for that matter) have pretty good networking stacks besides any new recent-gen WiFi.
- deleted 5y ago
  [deleted]
- loeg 5y ago
  C# support isn't great on FreeBSD yet, so probably not.
  - tester756 5y ago
    but if we assume that it works fine? AFAIK there's ongoing and active work for FreeBSD https://github.com/dotnet/runtime/issues/14537 https://github.com/dotnet/runtime/issues/14537
    - loeg 5y ago
      That issue has been continuously open since 2015. Assuming it works, sure, but I would not hold my breath.
lou1306 5y ago
Relevant: If your SSH server is public, you can give its address to https://sshcheck.com/ https://sshcheck.com/ and it will report any weak spots in your config.
- qersist3nce 5y ago
  nice honeypot ;) (joking, thanks for the suggestion)
- dspillett 5y ago
  Useful. Though I'll have to hunt out (or try knock together) something that we can run locally for checking internal-only/white-listed hosts (like https://testssl.sh/ https://testssl.sh/ for HTTPS config checking).
- crispyambulance 5y ago
  Thanks, that's an interesting tool. But geezus, it's daunting to address SSH weaknesses unless you know ssh and it's configuration top to bottom. I don't! And I am not afraid to admit it. I just use ssh "as-is" on mainstream platforms, for example, whatever Amazon gives me on lightsail linux images or windows-10 or whatever's on my Mac and hope for the best. I mean, there's 4 different groups of algorithms to think about: "Key Exchange", "Server Host Key", "Encryption" and "MAC". Each with a bunch of choices, all different, all consisting of mouthfuls of impossible to remember complicated names. The sshcheck tool indicates that one of these is "insecure" because it may be "broken by nation states". What does that _really_ mean for a business or individual? ¯\_(ツ)_/¯ There are others which are labeled as "weak" so what does that mean? That it might someday be broken by nation-states? I think it's still useful, however. Why wouldn't you want to have the most secure ssh connections if it's just a matter of configuration? Ultimately, someone who uses the report from sshcheck has to decide whether it's worth it to google around, spend a solid 30 minutes or so, and figure out how to change their "out-of-the-box" ssh config to get a fully secure report from sshcheck.
  - chasil 5y ago
    If you like Wireguard's security, you can emulate it in your sshd_config: Ciphers chacha20-poly1305@openssh.com KexAlgorithms curve25519-sha256@libssh.org MACs hmac-sha2-512-etm@openssh.com The MAC is irrelevant, as that function is built into the AEAD cipher, which are to be preferred (the alternate is AES-GCM). This will shut off a lot of legacy SSH clients. Android Connectbot specifically needs the AES cipher; adding it causes problems for putty. Otherwise, this is the classic "best practice" site for SSH: https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht...
lamnk 5y ago
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. Second is to disable root login. Third is to copy my private key over and disable password login. 3 essential steps to secure SSH.
- kd913 5y ago
  I think there are better approaches than this. 1) Setup a VPN via wireguard and only expose that random udp port. That way only a single UDP port is exposed and port-scans become infeasible. 2) Setup 2fa via libpam-google
  - mercora 5y ago
    ssh is typically the only thing i expose (publicly if needed) because in most environments were it is running it is used for troubleshooting issues. if your issue is that your wireguard peer cant connect you are lost with that suggestion.
  - RealStickman_ 5y ago
    What would you do if your Wireguard tunnel dies? That's the one thing that's prevented me from actually doing this.
    - kd913 5y ago
      I have 5 locations running effectively independent VPNs, each hub connected to each other for redundancy if a VPN falls over. i.e. Each hub has 1 VPN in, or is connecting 4 ways out. If the port forwarding or something fails inbound, then I can connect via another VPN and try and debug/diagnose what is wrong. If all VPNs are reporting down, then I know the pi/internet is completely down. It will either restart connectivity, but I have someone there who can plug/unplug/restore the system if necessary. The same kind of problem would occur if ssh falls over or wireguard.
    - akerl_ 5y ago
mkj 5y ago
It generates a new RSA key but disables it in the config? Seems a bit much mindless cut and paste.
hannob 5y ago
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. 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.
- ipaddr 5y ago
  Safest setup disable password login. disable ssh login. Put the computer back in the box and put the box under your bed.
  - 0xdeadb00f 5y ago
    Then, using aluminum foil and unfolded crisp packets make your room into a Faraday cage. Never open the door for any reason whatsoever. In fact, remove the door altogether.
    - 0xFFFE 5y ago
      Ensure lead bricks are used to build the said room.
      - doubled112 5y ago
        Lead is good, but I think it'd be easy to melt through. Better add another layer of something more temperature resistant. Defense in depth.
    - lizknope 5y ago
      I absolutely disable sshd on machines where I never need to login remotely like my laptops. My servers of course run sshd.
- acatton 5y ago
  In the same vein, protecting your SSH server with spiped[1] does 99% of the job. (= No need to setup fail2ban, password auth is not a big deal anymore, protects against out-of-date SSH servers and/or zero-days exploits, ...) [1] https://www.tarsnap.com/spiped.html https://www.tarsnap.com/spiped.html
chasil 5y ago
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? E521 is listed as safe on DJB's main evaluation site: https://safecurves.cr.yp.to/ https://safecurves.cr.yp.to/ 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." http://blog.cr.yp.to/20140323-ecdsa.html http://blog.cr.yp.to/20140323-ecdsa.html I believe that OpenSSH is using the E521 provided by OpenSSL (as seen on Red Hat 7): $ 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 These appear to have been contributed by Sun Microsystems, and were designed to avoid patent infringement. https://security.stackexchange.com/questions/3519/can-ecc-be-used-without-infringing-on-patents https://security.stackexchange.com/questions/3519/can-ecc-be...
- rdpintqogeogsaa 5y ago
  Ignoring the fact that some of the SafeCurves criteria are questionable (reasonably performant complete short Weierstrass formulae have existed for a while; indistinguishability is a complete niche feature that is hardly ever required)... These are not the same curves. NIST P-521 is a short Weierstrass curve defined by NIST. E-521 is an Edwards curve introduced by Aranha/Barreto/Pereira/Ricardini. NIST P-521: y^2 = x^3 - 3x + 0x51953EB9618E1C9A1F929A21A0B68540EEA2DA725B99B315F3B8B489918EF109E156193951EC7E937B1652C0BD3BB1BF073573DF883D2C34F1EF451FD46B503F00 E-521: x^2 + y^2 = 1 - 376014x^2y^2 The only thing they share is the finite field over which they're defined, GF(2^521 - 1).
  - chasil 5y ago
    Thank you for the clarification. Does this reduce the safety of an OpenSSH ECDSA key defined at 521 bits? That large constant is not reassuring, despite DJB's direct commentary.
    - 5y ago
tiffanyh 5y ago
NanoBSD? 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. 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. https://docs.freebsd.org/en/articles/nanobsd/ https://docs.freebsd.org/en/articles/nanobsd/
- enduser 5y ago
  I looked into this for a project a couple of years ago (to boot VMs from minimal customized ISO) and ended up using mfsbsd instead. https://github.com/mmatuska/mfsbsd https://github.com/mmatuska/mfsbsd
  - tiffanyh 5y ago
    That's interesting, this appears to be created by a core FreeBSD developer. https://mfsbsd.vx.sk https://mfsbsd.vx.sk I'm not able to find a lot of documentation on it. How does it compare to NanoBSD (and why did you choose it over Nano)?
    - enduser 5y ago
      mfsbsd builds a custom live CD using an easily-customized Makefile. NanoBSD expects multiple partitions, some of which are mutable, so is more oriented toward booting small systems from flash. For my purposes I needed an application server that would reboot to a known-good state, so I embedded the application code inside a mfsbsd live CD.
  - robohoe 5y ago
    I've used Martin Matuska's mfsbsd in the past to install a system with ZFS on root. I believe now that's natively supported, but back in the day it was quite an involved thing :)
beermonster 5y ago
When using the SSH protocol for running automated remote commands you can improve security using forced command[1] within your authorized_keys file. [1] https://ctrlnotes.com/restrict-a-user-to-ssh-forced-command/# https://ctrlnotes.com/restrict-a-user-to-ssh-forced-command/...
- rsync 5y ago
  ... and you can also restrict by IP address in authorized_keys ...
  - beermonster 5y ago
    Ah yes, before your key type specifier i.e. at the very beginning use something like : from="192.168.1.0/24"
samgranieri 5y ago
I like reading tutorials on this subject. One of my favorites, albeit six years old, is https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht...
beermonster 5y ago
Not everyone knows that you can use MFA with SSH. I’ve successfully used Google authenticator via PAM[1] and YubiKey[2]. You can also setup SSH certificate authorities instead of using self-signed ones [3] [1] https://wiki.archlinux.org/title/Google_Authenticator https://wiki.archlinux.org/title/Google_Authenticator [2] https://developers.yubico.com/SSH/ https://developers.yubico.com/SSH/ [3] https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-certificate-authority/ https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-cer...
- akerl_ 5y ago
  Jumping on the bandwagon here, SSH also now supports FIDO/U2F. This allows for hardware security keys like Yubikeys to be used directly for auth, rather than via TOTP/HOTP codes. https://www.openssh.com/txt/release-8.2 https://www.openssh.com/txt/release-8.2
  - beermonster 5y ago
    Oh neat! Didn’t know that :)
  - tialaramex 5y ago
    The FIDO tokens have no intention of allowing you to do anything else except FIDO with their keys (in fact the cheapest ones literally couldn't if they wanted to, good) and the SSH protocol of course was not originally designed for these tokens (it's from last century!) so the result is that the OpenSSH team had to design a custom key type for this purpose. In consequence, although this technology is excellent and I endorse choosing it especially in tandem with other FIDO usage (e.g. WebAuthn for web sites, and I believe Windows can use it to authenticate users to their desktops/ laptops) you need to understand that both sides must have the necessary feature for it to authenticate you, both your clients and any SSH servers you need to authenticate against must recognise the FIDO-specific auth method in SSH. If you mostly administrate shiny modern *BSD or Linux boxes, they have a new enough OpenSSH, so this Just Works™. But if you've got some creaky five year old VMs or worse real servers running like RHEL 6 or something, that may be an obstacle to practically deploying this. Good news is that this will improve over time, and e.g. GitHub did eventually learn the new key type.
deleted 5y ago
[deleted]

164 points by rodrigo975 5y ago

I always heard that FreeBSD has unparalleled networking 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)

deleted 5y ago
[deleted]
kd913 5y ago
I don't think it would be worthwhile. If you want better latency and throughput, you wouldn't be using the kernel network stack and instead be opting for some userspace networking stack like DPDK or onload. Depends obviously on what the bottlenecks of your application are, your NIC and the characteristics of your hardware as well.
- crest 5y ago
  FreeBSD has netmap for fast userspace packet processing.
  - kd913 5y ago
    True, and the Linux kernel has zero-copy AF_XDP that enable memory to be shared with userspace. However, low-latency networking is a lot more than just simple kernel bypass. It's things like pinning cpu cores dedicated for networking, disabling C-states, epolling and being able to utilize bespoke firmware interfaces designed for smartnics. Also application protocol, ie using features like TCP checksum offload and TSO. Heck the application would also need to be adjusted for a low-latency environment via probably a custom JVM and doing things like reading data structures/variables to ensure they are in CPU cache. Frankly I would recommend trying openonload which at least is compatible with native Linux socket programming unlike DPDK.
- almalkemqq 5y ago
  I loved the simple explanation :)
toast0 5y ago
As with all things, you would really need to benchmark the system, preferably with real load, both ways to know for sure. But that takes a lot of time, especially if you're going to put in the time to tweak both systems. People can do amazing stuff with enough time in both FreeBSD and Linux. I honestly think most server applications wouldn't be held back by either OS. You need your application to be really lightweight and focused before the OS makes a big difference, and even then, the differences only show if you're maxing out the hardware. I worked at WhatsApp, and enjoyed working with FreeBSD there, and clearly it worked for us. Linux in FB datacenters also worked, but the server components were a lot different so there was never an apples to apples comparison. I run FreeBSD on my personal servers because I enjoyed working with it at Yahoo and then WhatsApp; but my personal servers don't have any performance needs. Sure, the networking stuff is nice (and it was nice to work with in the kernel), but what I like most about FreeBSD is the lack of churn. I can look at old administrative recipies and all the commands still work. I can expect (and mostly get) that when I upgrade, everything will keep working, and maybe a little better; occassionally, a lot better.
- waynesonfire 5y ago
  > but what I like most about FreeBSD is the lack of churn I agree completely. As I mature in this field this becomes an ever important characteristic of the technology I adopt. Erlang also shares this property.
  - toast0 5y ago
    I feel like Erlang churn is more acceptable because they're usually honest in naming. You get pg2 which does what pg did, but differntly. And now pg (which could have been pg3, but the old pg had been gone long enough to reclaim the name). Similar with phash2, although phash may live for much longer.
- tiffanyh 5y ago
  Hi toast0 IIRC, I saw a presentation by someone (Rick?) where at your previous employer - you guys slimmed FreeBSD down to be unbelievably minimal such that only 2-3 total services ran on the entire server. Was that done for performance reason? Or for hardening reasons? If someone wanted to do that today with FreeBSD: would you recommend it and how would you go about doing it (NanoBSD)?
adrian_b 5y ago
There was a time when FreeBSD had much better networking performance than Linux, but that was many years ago. Now, on supported hardware, their performance should be similar. However, Linux has drivers for much more varied networking hardware. FreeBSD has very good support for Intel NIC's but some of the hardware from other vendors may happen to be not supported. FreeBSD has a few nicer kernel features for those who develop themselves a networking application, but more networking libraries useful for high performance applications are available for Linux, even if DPDK, which was mentioned in another reply, is available for both Linux and FreeBSD. So, while I am a very satisfied FreeBSD user, I would recommend to someone with less experience to use Linux, as there are more resources readily available. On the other hand, for someone who wants to learn more about the implementation of networking applications, it can be useful to also try FreeBSD, to understand more about alternative solutions.
0xdeadb00f 5y ago
FreeBSD (and all BSDs for that matter) have pretty good networking stacks besides any new recent-gen WiFi.
deleted 5y ago
[deleted]
loeg 5y ago
C# support isn't great on FreeBSD yet, so probably not.
- tester756 5y ago
  but if we assume that it works fine? AFAIK there's ongoing and active work for FreeBSD https://github.com/dotnet/runtime/issues/14537 https://github.com/dotnet/runtime/issues/14537
  - loeg 5y ago
    That issue has been continuously open since 2015. Assuming it works, sure, but I would not hold my breath.

lou1306 5y ago

Relevant: If your SSH server is public, you can give its address to https://sshcheck.com/ https://sshcheck.com/ and it will report any weak spots in your config.

qersist3nce 5y ago
nice honeypot ;) (joking, thanks for the suggestion)
dspillett 5y ago
Useful. Though I'll have to hunt out (or try knock together) something that we can run locally for checking internal-only/white-listed hosts (like https://testssl.sh/ https://testssl.sh/ for HTTPS config checking).
crispyambulance 5y ago
Thanks, that's an interesting tool. But geezus, it's daunting to address SSH weaknesses unless you know ssh and it's configuration top to bottom. I don't! And I am not afraid to admit it. I just use ssh "as-is" on mainstream platforms, for example, whatever Amazon gives me on lightsail linux images or windows-10 or whatever's on my Mac and hope for the best. I mean, there's 4 different groups of algorithms to think about: "Key Exchange", "Server Host Key", "Encryption" and "MAC". Each with a bunch of choices, all different, all consisting of mouthfuls of impossible to remember complicated names. The sshcheck tool indicates that one of these is "insecure" because it may be "broken by nation states". What does that _really_ mean for a business or individual? ¯\_(ツ)_/¯ There are others which are labeled as "weak" so what does that mean? That it might someday be broken by nation-states? I think it's still useful, however. Why wouldn't you want to have the most secure ssh connections if it's just a matter of configuration? Ultimately, someone who uses the report from sshcheck has to decide whether it's worth it to google around, spend a solid 30 minutes or so, and figure out how to change their "out-of-the-box" ssh config to get a fully secure report from sshcheck.
- chasil 5y ago
  If you like Wireguard's security, you can emulate it in your sshd_config: Ciphers chacha20-poly1305@openssh.com KexAlgorithms curve25519-sha256@libssh.org MACs hmac-sha2-512-etm@openssh.com The MAC is irrelevant, as that function is built into the AEAD cipher, which are to be preferred (the alternate is AES-GCM). This will shut off a lot of legacy SSH clients. Android Connectbot specifically needs the AES cipher; adding it causes problems for putty. Otherwise, this is the classic "best practice" site for SSH: https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

lamnk 5y ago

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. Second is to disable root login. Third is to copy my private key over and disable password login. 3 essential steps to secure SSH.

kd913 5y ago
I think there are better approaches than this. 1) Setup a VPN via wireguard and only expose that random udp port. That way only a single UDP port is exposed and port-scans become infeasible. 2) Setup 2fa via libpam-google
- mercora 5y ago
  ssh is typically the only thing i expose (publicly if needed) because in most environments were it is running it is used for troubleshooting issues. if your issue is that your wireguard peer cant connect you are lost with that suggestion.
- RealStickman_ 5y ago
  What would you do if your Wireguard tunnel dies? That's the one thing that's prevented me from actually doing this.
  - kd913 5y ago
    I have 5 locations running effectively independent VPNs, each hub connected to each other for redundancy if a VPN falls over. i.e. Each hub has 1 VPN in, or is connecting 4 ways out. If the port forwarding or something fails inbound, then I can connect via another VPN and try and debug/diagnose what is wrong. If all VPNs are reporting down, then I know the pi/internet is completely down. It will either restart connectivity, but I have someone there who can plug/unplug/restore the system if necessary. The same kind of problem would occur if ssh falls over or wireguard.
  - akerl_ 5y ago

mkj 5y ago

It generates a new RSA key but disables it in the config? Seems a bit much mindless cut and paste.

hannob 5y ago

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

ipaddr 5y ago
Safest setup disable password login. disable ssh login. Put the computer back in the box and put the box under your bed.
- 0xdeadb00f 5y ago
  Then, using aluminum foil and unfolded crisp packets make your room into a Faraday cage. Never open the door for any reason whatsoever. In fact, remove the door altogether.
  - 0xFFFE 5y ago
    Ensure lead bricks are used to build the said room.
    - doubled112 5y ago
      Lead is good, but I think it'd be easy to melt through. Better add another layer of something more temperature resistant. Defense in depth.
  - lizknope 5y ago
    I absolutely disable sshd on machines where I never need to login remotely like my laptops. My servers of course run sshd.
acatton 5y ago
In the same vein, protecting your SSH server with spiped[1] does 99% of the job. (= No need to setup fail2ban, password auth is not a big deal anymore, protects against out-of-date SSH servers and/or zero-days exploits, ...) [1] https://www.tarsnap.com/spiped.html https://www.tarsnap.com/spiped.html

chasil 5y ago

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? E521 is listed as safe on DJB's main evaluation site: https://safecurves.cr.yp.to/ https://safecurves.cr.yp.to/ 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." http://blog.cr.yp.to/20140323-ecdsa.html http://blog.cr.yp.to/20140323-ecdsa.html I believe that OpenSSH is using the E521 provided by OpenSSL (as seen on Red Hat 7): $ 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 These appear to have been contributed by Sun Microsystems, and were designed to avoid patent infringement. https://security.stackexchange.com/questions/3519/can-ecc-be-used-without-infringing-on-patents https://security.stackexchange.com/questions/3519/can-ecc-be...

rdpintqogeogsaa 5y ago
Ignoring the fact that some of the SafeCurves criteria are questionable (reasonably performant complete short Weierstrass formulae have existed for a while; indistinguishability is a complete niche feature that is hardly ever required)... These are not the same curves. NIST P-521 is a short Weierstrass curve defined by NIST. E-521 is an Edwards curve introduced by Aranha/Barreto/Pereira/Ricardini. NIST P-521: y^2 = x^3 - 3x + 0x51953EB9618E1C9A1F929A21A0B68540EEA2DA725B99B315F3B8B489918EF109E156193951EC7E937B1652C0BD3BB1BF073573DF883D2C34F1EF451FD46B503F00 E-521: x^2 + y^2 = 1 - 376014x^2y^2 The only thing they share is the finite field over which they're defined, GF(2^521 - 1).
- chasil 5y ago
  Thank you for the clarification. Does this reduce the safety of an OpenSSH ECDSA key defined at 521 bits? That large constant is not reassuring, despite DJB's direct commentary.
  - 5y ago

tiffanyh 5y ago

NanoBSD? 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. 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. https://docs.freebsd.org/en/articles/nanobsd/ https://docs.freebsd.org/en/articles/nanobsd/

enduser 5y ago
I looked into this for a project a couple of years ago (to boot VMs from minimal customized ISO) and ended up using mfsbsd instead. https://github.com/mmatuska/mfsbsd https://github.com/mmatuska/mfsbsd
- tiffanyh 5y ago
  That's interesting, this appears to be created by a core FreeBSD developer. https://mfsbsd.vx.sk https://mfsbsd.vx.sk I'm not able to find a lot of documentation on it. How does it compare to NanoBSD (and why did you choose it over Nano)?
  - enduser 5y ago
    mfsbsd builds a custom live CD using an easily-customized Makefile. NanoBSD expects multiple partitions, some of which are mutable, so is more oriented toward booting small systems from flash. For my purposes I needed an application server that would reboot to a known-good state, so I embedded the application code inside a mfsbsd live CD.
- robohoe 5y ago
  I've used Martin Matuska's mfsbsd in the past to install a system with ZFS on root. I believe now that's natively supported, but back in the day it was quite an involved thing :)

beermonster 5y ago

When using the SSH protocol for running automated remote commands you can improve security using forced command[1] within your authorized_keys file. [1] https://ctrlnotes.com/restrict-a-user-to-ssh-forced-command/# https://ctrlnotes.com/restrict-a-user-to-ssh-forced-command/...

rsync 5y ago
... and you can also restrict by IP address in authorized_keys ...
- beermonster 5y ago
  Ah yes, before your key type specifier i.e. at the very beginning use something like : from="192.168.1.0/24"

samgranieri 5y ago

I like reading tutorials on this subject. One of my favorites, albeit six years old, is https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht...

beermonster 5y ago

Not everyone knows that you can use MFA with SSH. I’ve successfully used Google authenticator via PAM[1] and YubiKey[2]. You can also setup SSH certificate authorities instead of using self-signed ones [3] [1] https://wiki.archlinux.org/title/Google_Authenticator https://wiki.archlinux.org/title/Google_Authenticator [2] https://developers.yubico.com/SSH/ https://developers.yubico.com/SSH/ [3] https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-certificate-authority/ https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-cer...

akerl_ 5y ago
Jumping on the bandwagon here, SSH also now supports FIDO/U2F. This allows for hardware security keys like Yubikeys to be used directly for auth, rather than via TOTP/HOTP codes. https://www.openssh.com/txt/release-8.2 https://www.openssh.com/txt/release-8.2
- beermonster 5y ago
  Oh neat! Didn’t know that :)
- tialaramex 5y ago
  The FIDO tokens have no intention of allowing you to do anything else except FIDO with their keys (in fact the cheapest ones literally couldn't if they wanted to, good) and the SSH protocol of course was not originally designed for these tokens (it's from last century!) so the result is that the OpenSSH team had to design a custom key type for this purpose. In consequence, although this technology is excellent and I endorse choosing it especially in tandem with other FIDO usage (e.g. WebAuthn for web sites, and I believe Windows can use it to authenticate users to their desktops/ laptops) you need to understand that both sides must have the necessary feature for it to authenticate you, both your clients and any SSH servers you need to authenticate against must recognise the FIDO-specific auth method in SSH. If you mostly administrate shiny modern *BSD or Linux boxes, they have a new enough OpenSSH, so this Just Works™. But if you've got some creaky five year old VMs or worse real servers running like RHEL 6 or something, that may be an obstacle to practically deploying this. Good news is that this will improve over time, and e.g. GitHub did eventually learn the new key type.

deleted 5y ago

[deleted]