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

81–90 of 121 posts

Re: FreeBSD SSH Hardening

#81

Post by tialaramex »

ilaksh wrote: post #76
BelenusMordred wrote: post #32

Earlier quoted context omitted.

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

So.

All of today's practical public key crypto could be broken by a sufficiently powerful quantum computer - if one existed which today it does not - thanks to a trick called Shor's Algorithm.

However, there are new public key algorithms that aren't affected by Shor's algorithm. Two problems. 1. They're all worse, they have huge keys for example, or they're slow, so that sucks. 2. We don't know if they actually work, beyond that Shor's algorithm doesn't break them on hypothetical Quantum Computers.

Even if you decide you don't care about (1) and you're very scared of the hypothetical quantum computers (after all once upon a time the Atom Bomb was also hypothetical) you need to deal with (2).

Post-quantum schemes like this for SSH generally arrange that by doing two things, they have the shiny new Quantum Resistant algorithms, but they also have an old-fashioned public key algorithm, and you need to break both to break their security. Either alone won't help you.

Re: FreeBSD SSH Hardening

#82

Post by crispyambulance »

gautamcgoel wrote: post #78
crispyambulance wrote: post #25

Earlier quoted context omitted.

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

No, it's just a randomly chosen name (a British new wave band from the early 80's).

Re: FreeBSD SSH Hardening

#83

Post by doubled112 »

0xFFFE wrote: post #67
0xdeadb00f wrote: post #16

Earlier quoted context omitted.

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.

Ensure lead bricks are used to build the said room.

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.

Re: FreeBSD SSH Hardening

#84

Post by Panino »

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

Note that the above post-quantum key exchange method was removed in OpenSSH 8.5 (released March 3, 2021) in favor of a newer one:

sntrup761x25519-sha512@openssh.com

So if you add the previous one to your server config, sshd may fail to start after upgrading to 8.5 or newer (8.7 is the most recent release).

I started using sntrup4591761x25519-sha512@tinyssh.org about two years ago, and the new one when OpenSSH 8.5 came out. They've both worked flawlessly for me. Thank you to TinySSH and OpenSSH, and of course cryptographers, for making this possible.

Re: FreeBSD SSH Hardening

#85

Post by staticassertion »

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

I was just searching for someone bringing this up. Of any advice I could give someone setting up SSH it would be to use a FIDO key + short lived sessions.

Re: FreeBSD SSH Hardening

#86

Post by bityard »

acatton wrote: post #23
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…

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

spiped looks like netcat with symmetric encryption. If your SSH server has password auth disabled, then all you're doing is moving the attack surface from one thing to another.

You're making a trade-off no matter which way you go. spiped probably has a smaller attack surface than sshd due to being less code, but it's also less "tried and true" than openssh. Not to mention, managing symmetric keys securely is more difficult than with asymmetric openssh keys where you generally only need to copy around the public key.

OpenSSH is plenty secure enough to be exposed to the public internet as long as you keep it up to date and do not have it misconfigured. But if you have a strong reason to not make it public, then I feel that something like Wireguard is really a better way to go.

Re: FreeBSD SSH Hardening

#87

Post by sillysaurusx »

cperciva wrote: post #36
tiffanyh wrote: post #30

Earlier quoted context omitted.

Is Spiped similar in-concept to a VPN?

Sort of. Not really. spiped operates at the level of individual stream connections, so you can e.g. make one end a local socket in a filesystem and use UNIX permissions to control access to it. In fact that's exactly why I wrote it -- so I could have a set of daemons designed to communicate via local sockets and transparently (aside from performance) have them running on different systems.

Is it possible to use tarsnap's deduplication code on my own server? We're setting up an ML dataset distribution box, and I was hoping to avoid storing e.g. imagenet as a tarball + untar'd (so that nginx can serve each photo individually) + imagenet in TFDS format.

https://github.com/xolox/dedupfs was the closest I found, but it has a lot of downsides.

Has anyone made an interface to tarsnap's tarball dedup code? A python wrapper around the block dedup code would be ideal, but I doubt it exists.

(Sorry for the random question -- I was just hoping for a standalone library along the lines of tarsnap's "filesystem block database" APIs. I thought about emailing this to you instead, but I'm crossing my fingers that some random HN'er might know. I'm sort of surprised that filesystems don't make it effortless. In fact, I delayed posting this for an hour to go research whether ZFS is the actual solution -- apparently "no, not unless you have specific brands of SSDs: https://www.truenas.com/community/resources/my-experiments-i..." which rules out my non-SSD 64TB Hetzner server. But like, dropbox solved this problem a decade ago -- isn't there something similar by now?)

EDIT: How timely -- Wyng (https://news.ycombinator.com/item?id=28537761) was just submitted a few hours ago. It seems to support "Data deduplication," though I wonder if it's block-level or file-level dedup. Tarsnap's block dedup is basically flawless, so I'm keen to find something that closely matches it.

Re: FreeBSD SSH Hardening

#88

Post by ur-whale »

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.

>f your Wireguard tunnel dies?

wireguard tunnels are pretty robust to failure.

they can survive you changing your wifi access point and IP for example.

Re: FreeBSD SSH Hardening

#89

Post by loeg »

tester756 wrote: post #79
loeg wrote: post #70

Earlier quoted context omitted.

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

That issue has been continuously open since 2015. Assuming it works, sure, but I would not hold my breath.

Re: FreeBSD SSH Hardening

#90

Post by GoblinSlayer »

chasil wrote: post #14

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

AIU, E-521 is not P-521.
Post reply on HN