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

41–50 of 121 posts

Re: FreeBSD SSH Hardening

#41

Post by tiffanyh »

enduser wrote: post #39
tiffanyh wrote: post #31

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…

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

That's interesting, this appears to be created by a core FreeBSD developer.

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

Re: FreeBSD SSH Hardening

#42

Post by mercora »

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

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.

Re: FreeBSD SSH Hardening

#43

Post by RealStickman_ »

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

What would you do if your Wireguard tunnel dies?

That's the one thing that's prevented me from actually doing this.

Re: FreeBSD SSH Hardening

#44

Post by mercora »

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.

Re: FreeBSD SSH Hardening

#45

Post by akerl_ »

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

Re: FreeBSD SSH Hardening

#46

Post by rdpintqogeogsaa »

chasil wrote: post #28
rdpintqogeogsaa wrote: post #27

Earlier quoted context omitted.

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…

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.

To the best of my current knowledge, it's at most possible that the NSA backdoored the NIST curves. I'm unaware of anyone in academia positively proving the existence thereof.

If your threat model doesn't include the NSA or other intelligence agency level state actors, ECDSA with NIST P-521 will serve you just fine.

(ECDSA is per se a questionable abuse of elliptic curves born from patent issues now long past, but it's not a real, exploitable security problem, either, if implemented correctly.)

Re: FreeBSD SSH Hardening

#47

Post by binkHN »

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.

I tried out the tool, and all I got was a “Timeout exceeded while waiting for welcome message.”

For every public SSH server I put up, I always configure a rate limiter in front of it to help thwart SSH attacks. Evidently, it thwarts this as well.

Re: FreeBSD SSH Hardening

#48

Post by rsync »

beermonster wrote: post #35

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

... and you can also restrict by IP address in authorized_keys ...

Re: FreeBSD SSH Hardening

#49

Post by akerl_ »

Saint_Genet wrote: post #29
akerl_ wrote: post #26

Earlier quoted context omitted.

As I said: changing the port is just a means to avoid having to `apt install logrotate` Active alerting on brute force attempts on an internet-facing SSH service is an exercise in human suffering. At best you don’t get any alerts, and at worst you get alerts that you do… what, precisely, with? Block the IP? Look up the “human” attacker and send them an email asking them to stop? There are environments and entities fo…

Only if you never read your logs.

I feel like this doesn’t actually address any of my comment.

I’m specifically saying that the act of reading SSH logs for an internet-facing server is an exercise in futility. The kinds of things that will show up in the logs (brute force attempts, generally nmapping, etc) are not credible risks to even a largely unconfigured SSH daemon (as noted elsewhere in this thread, the bar to have an above average secure SSH service is basically “apply pubkey, disable password auth, celebrate”).

The attackers that are problematic don’t look out of place in your logs: somebody who stole a valid pubkey/password, the unlikely case of an SSH zero day, etc. Those are going to be single access attempts that just work. Unless you’re literally alerting on every successful auth, the logs aren’t helping you for active alerting.

Keeping your internet-facing SSH logs is important for investigative work: once you find out that your buddy accidentally put their private key in a pastebin, you can check if somebody used it to log into your server.

Re: FreeBSD SSH Hardening

#50

Post by akerl_ »

RealStickman_ wrote: post #43
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

What would you do if your Wireguard tunnel dies? That's the one thing that's prevented me from actually doing this.

The same thing that happens if the SSH daemon dies, I guess?

FWIW, I’ve been using Wireguard for a while (probably ~2 years?) as an always-on VPN for multiple mobile devices, and also as a reverse tunnel to pinhole service access inside a LAN. The Wireguard config and daemon has been rock solid. The only time it’s failed is when I messed up the AllowedIPs, but that failure occurs at configuration time. It has never crashed, or stopped routing traffic correctly, or otherwise failed in a way that interrupted traffic flows.

Post reply on HN