Live data from Hacker News

FreeBSD SSH Hardening

gist.github.com

101–110 of 121 posts

Re: FreeBSD SSH Hardening

#101
post #57

Earlier quoted context omitted.

OpenVPN may have its issues (complicated setup vs. e.g. Wireguard, but not vs. e.g. IPsec), but I wouldn’t call it “not good” and it predates spiped by a decade.

Ok. I don’t agree there. What I’ve heard from security experts is that WireGuard is vastly superior to OpenVPN. Addendum: OpenVPN was released in 2001 and there where lots of cryptography-related systems from that era that certainly didn’t age well – IMO OpenVPN is one of those examples.

> security experts is that WireGuard is vastly superior to OpenVPN

Superior doesn’t imply the other is “not good”.

> lots of cryptography-related systems from that era that certainly didn’t age well

This doesn’t really mean anything.

> IMO OpenVPN is one of those example

That’s your opinion, but so far you’ve given no evidence.

As the other commenter said: OpenVPN is just TLS via OpenSSL. Yes, at some points it has used now-insecure algorithms, but so have web browsers and most everything else. One wouldn’t configure OpenVPN today the way they did in 2001.

Not that it necessarily means much, but AWS Client VPN is just OpenVPN. AWS, GCP, & Azure all support IPsec VPN which dates back to the ’90s. Just because something has been around for a long time doesn’t mean it hasn’t evolved its cryptography at all.

Re: FreeBSD SSH Hardening

#102
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

I prefer tinyssh to dropbear and even to openssh. https://github.com/janmojzis/tinyssh Its not for the tinfoil, the reason is the size. OpenSSH is too large for some small systems. In June, dropbear finally got support for chacha20-poly1305 and ed25519 keys, but it only offers the TweetNaCl version. tinyssh has had this since 2014 and can use the original NaCl library, not just the Twitter version.

tinyssh does what the top comment comment in this thread suggests, and in fact goes further. It does not include bad algorithms. This is arguably better than only "deprecating" them.

Re: FreeBSD SSH Hardening

#103

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

And you can use a Yubikey hardware key as a ecdsa-sha2-nistp384 secret store, without messing with PAM or needing custom key types or special files on the client host: https://github.com/FiloSottile/yubikey-agent

Re: FreeBSD SSH Hardening

#104
post #84

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

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

I actually filed the github request for Jan Mojžíš to update TinySSH with the new KEX.

I run tinysshd on some RedHat 5 servers, and I rely upon the latest post-quantum exchange. I also jack all my putty users into it with an agent, and I don't assign them passwords.

It would be nice if I was allowed to upgrade from RedHat 5, but I am not.

Re: FreeBSD SSH Hardening

#105

Earlier quoted context omitted.

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

You can look into btrfs and duperemove for offline dedupe.

Re: FreeBSD SSH Hardening

#106
post #105

Earlier quoted context omitted.

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

You can look into btrfs and duperemove for offline dedupe.

Thanks!

Re: FreeBSD SSH Hardening

#107
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…

[deleted]

Re: FreeBSD SSH Hardening

#108

Earlier quoted context omitted.

> Has anyone made an interface to tarsnap's tarball dedup code? Tarsnap's deduplication code is not available under an open-source license.

True, but a couple years ago I ported most of the Tarsnap dedup algorithms to Python. It wasn't too hard, just time consuming. I was hoping someone else did that in a thorough way, but I guess the intersection of "I love tarsnap's design!" and "I have the time to port it from C!" might not be too large.

This may be a foolish question, but if the dedup code isn’t open source, how did you port it to Python?

Re: FreeBSD SSH Hardening

#109
post #108

Earlier quoted context omitted.

True, but a couple years ago I ported most of the Tarsnap dedup algorithms to Python. It wasn't too hard, just time consuming. I was hoping someone else did that in a thorough way, but I guess the intersection of "I love tarsnap's design!" and "I have the time to port it from C!" might not be too large.

This may be a foolish question, but if the dedup code isn’t open source, how did you port it to Python?

Not foolish! The Tarsnap client code is open source, but the license file prohibits anyone from using the code: https://github.com/Tarsnap/tarsnap/blob/master/COPYING

> Redistribution and use in source and binary forms, without modification, is permitted for the sole purpose of using the "tarsnap" backup service provided by Tarsnap Backup Inc.

The codebase is a jewel. I love the design, the way it's organized, the coding style, the algorithms, everything.

My process was to skim Colin's thesis: http://www.daemonology.net/papers/thesis.pdf

Along with the rsync thesis: https://www.samba.org/~tridge/phd_thesis.pdf

Then I started making a mental map of tarsnap: How does it build its deduplication index? How does it decide where block boundaries start within a file? Etc.

Eventually I started coding the algorithms in Python, mostly as a way of understanding the code. It's not actually as hard as it sounds, but you have to be rigorous. (It's a C -> Python conversion, after all, so there's not much room for error.)

My process was basically: Copy the C code into a Python file; comment out the code; for each line, write the corresponding Python; try to get something running as quickly as possible.

It worked pretty well, but I eventually lost interest.

Over the years, I've wanted a deduplication library, and 2021 is no exception. Someday I'll just roll up my sleeves and finish porting it.

Re: FreeBSD SSH Hardening

#110
post #34

Earlier quoted context omitted.

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; add…

Exactly my finding too! Except certain version of MacOS (and Windows) ssh client would also be unable to connect.

You can brew install openssh on MacOS.
Post reply on HN