Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FreeBSD SSH Hardening

gist.github.com

Post reply on HN
Print view View original

71–80 of 121 posts

Re: FreeBSD SSH Hardening

#71

Post by lizknope »

LinuxBender wrote: post #22
akerl_ wrote: post #20

Earlier quoted context omitted.

Just so we’re clear, this is 1 step to secure SSH, 1 step to avoid installing logrotate, and 1 step to encourage good admin practices. Changing the port and using a non-root user for SSH don’t appreciably change the strength of the server’s security.

Changing the port is obfuscation and by itself would not enhance security, however it does preclude all the noise from the automated bots. This allows you to have better alerting on brute force attempts because all of those attempts are a human manually targeting your server. The end result is effectively a better security posture. I have servers sprinkled all over the internet and in the last 30 years or so bots hav…

I got a new cloud virtual machine and didn't login for 2 hours. When I did the logs showed there were about 50 attempts to login from random IP addresses.

I changed my port to a random 4 digit number. Not a single failed login attempt in 6 months.

Obviously follow good security practices too but I like not have to rotate and filter the logs with yet another tool.

Re: FreeBSD SSH Hardening

#72

Post by lamnk »

mercora wrote: post #44
lamnk wrote: post #9

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.

please do not copy your private key to remote machines ;) you can use the ssh-copy-id tool it does the right thing for you.

yeah, my mistake, i meant to write copy the public key :D copying by hand is ok but ssh-copy-id is simpler. Can't edit the comment now hmmm...

Re: FreeBSD SSH Hardening

#73

Post by tiffanyh »

toast0 wrote: post #7
tester756 wrote: post #2

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)

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 lightweigh…

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

Re: FreeBSD SSH Hardening

#74

Post by lamnk »

kd913 wrote: post #19
lamnk wrote: post #9

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.

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

Yes, at work we use OpenVPN and only expose VPN, HTTP, HTTPS ports to the public.

But I find VPN a bit overkill on my personal machines.

Re: FreeBSD SSH Hardening

#75

Post by tialaramex »

akerl_ wrote: post #45
beermonster wrote: post #38

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 [2] https://developers.yubico.com/SSH/ [3] https://jameshfisher.com/2018/03/16/how-to-create-an-ssh-cer...

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

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.

Re: FreeBSD SSH Hardening

#76

Post by ilaksh »

BelenusMordred wrote: post #32
hannob wrote: post #13

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 b…

> None of the algorithms enabled by default has any known security issue. For the tinfoil among us, jump on the post-quantum key exchange train, there's little overhead, it still uses traditional elliptic curve crypto, best of both worlds. The jump-off: sntrup4591761x25519-sha512@tinyssh.org

What's a post-quantum key exchange? I assume this is a real thing and not a reference to Devs or Lapsis or something?

Re: FreeBSD SSH Hardening

#77

Post by kd913 »

lamnk wrote: post #74
kd913 wrote: post #19

Earlier quoted context omitted.

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

Yes, at work we use OpenVPN and only expose VPN, HTTP, HTTPS ports to the public. But I find VPN a bit overkill on my personal machines.

My use for it was to have a 5 way residential VPN across multiple Countries for obvious reasons. That wouldn't really suffice with just ssh. It also makes the shared infrastructure a lot easier to use for the rest of my family.

Also a globally accessible pihole connected to DoH which ensures somewhat global privacy.

They are basically my perfect use for my raspberry pis. Extremely low power, but perfectly capable for handling say 1080p video streams or to RDP into machines for access to cross-country resources.

Re: FreeBSD SSH Hardening

#78

Post by gautamcgoel »

crispyambulance wrote: post #25
lou1306 wrote: post #8

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

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 a…

Yo, do you play Supreme Commander? I think I saw someone with your username on FAF...

Re: FreeBSD SSH Hardening

#79

Post by tester756 »

loeg wrote: post #70
tester756 wrote: post #2

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)

C# support isn't great on FreeBSD yet, so probably not.

but if we assume that it works fine?

AFAIK there's ongoing and active work for FreeBSD

https://github.com/dotnet/runtime/issues/14537

Re: FreeBSD SSH Hardening

#80

Post by tester756 »

LinuxBender wrote: post #22
akerl_ wrote: post #20

Earlier quoted context omitted.

Just so we’re clear, this is 1 step to secure SSH, 1 step to avoid installing logrotate, and 1 step to encourage good admin practices. Changing the port and using a non-root user for SSH don’t appreciably change the strength of the server’s security.

Changing the port is obfuscation and by itself would not enhance security, however it does preclude all the noise from the automated bots. This allows you to have better alerting on brute force attempts because all of those attempts are a human manually targeting your server. The end result is effectively a better security posture. I have servers sprinkled all over the internet and in the last 30 years or so bots hav…

obscurity increases security, doesn't it?
Post reply on HN