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.
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.
True. But to be more specific, it does symmetric encryption and authentication.
> If your SSH server has password auth disabled, then all you're doing is moving the attack surface from one thing to another.
I get what you're saying. But I see spiped as port-knocking with a 256bits combination. So basically, you are reducing the attack surface. In order for the attacker to get through, they need a vulnerability in spiped and in openssh-server. (If these probabilities are 50-50 each, that means the overall probability is 0.25)
At the end of the day, spiped should run in a chroot, as a user, so the attack surface of spiped is really low. If it gets compromised, the only thing the attacker can do is "be able to try to establish a connection to the SSH server".
The goal of spiped for me is to eliminate the need for constant monitoring of openssh vulnerabilities, and for installing fail2ban/blacklistd (which can lock legitimate users out)
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.
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.
Tarsnap's deduplication code is not available under an open-source license.
> 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.
It works at the TCP level, not the IP level.
Now there is WireGuard, but it wasn’t launched until 2016.
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.
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.
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
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.
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.
Despite being sidelined in NIST's post quantum standardisation project it's interesting to see their Streamlined NTRU Prime algorithm still being the main real world adoption out there right now. I'd be interested if anyone knows of a more utilised post-quantum algo irl.
Bullseye is still on 8.4. OpenSSH on Windows appears to be 8.1.
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.
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.
That we know of. There are commercially available quantum computers [0] and there are roadmaps for commercial technology ramp up significantly [1]. Remember, that's a roadmap to projected commercial viability. It's hard to say what state actors are capable of right now.
[0]: https://azure.microsoft.com/en-us/services/quantum/
[1]: https://venturebeat.com/2020/12/09/ionq-roadmap-quantum-mach...
https://docs.freebsd.org/en/books/handbook/firewalls/#firewa...
disable password login. disable ssh login. Put the computer back in the box and put the box under your bed.
Better add another layer of something more temperature resistant. Defense in depth.