tinyssh is great. One use case for it that people may not know about: using it during Linux boot so you can remotely unlock encrypted drives. I have a headless NAS server that uses dm-crypt/LUKS under ZFS. When I update my kernel/ZFS I remotely reboot the server, wait a few seconds, and then ssh into a tinyssh powered encryption key prompt to unlock the drives. (I am immediately booted from ssh, as tinyssh exits.) I can then ssh again a few seconds later and I'm hitting openssh on a fully booted machine that wasn't able to open the drives without my intervention.
All fair, I guess I just landed on mkinitcpio-tinyssh first and it was my introduction to the idea, and only took a few seconds to setup. I'll switch to openssh if I ever have issues, but this has been working fine for many years, so I'm no rush.
Question: when remotely unlock the boot disk via ssh, how do you make sure the boot has not been compromised and that you are not just sending the password to the bad guys?
At some point I wanted to do something with utrablue [1], to work over network rather than Bluetooth, but then it was in go and I got lazy suddenly :)
> how do you make sure the boot has not been compromised and that you are not just sending the password to the bad guys?
In my case, I can't. This is a NAS in my house and this is mostly to prevent me from having to go to another room and plug in a monitor and keyboard. (Also, I've done this from across the country after a power outage.)
The threat vectors I'm protecting against are I guess mostly theft of the entire machine, or forgetting to wipe the drives when I eventually toss them out. Mostly, it's just fun practice because I'm a nerd and every drive should be encrypted.
For my use-case, the auto-unlock-by-polling-a-specific-LAN-IP linked in this thread would probably be fine, for example.
Well you can always drill holes in the platter, or hit them with a strong magnet, or just separate them and toss them in the trash. Unless you're fighting the NSA, you can probably get away with enough physical destruction to make recovery challenging.
In theory this should be a perfect match for TPM-powered secure booting: your machine starts every time with a clean TPM, which validates the BIOS into it, which validates the bootloader into it, which validates the kernel into it, which derives an RSA private key from the resulting TPM state. If an attacker compromises it, it'll present the wrong host key and you get a big fat error message.
Mandos tries to mitigate this problem by periodically checking that the rebooting server is still up. Exactly how this is done is configurable, but by default it uses ssh-keyscan to check if the server is up and using the SSH server key from its normal encrypted root file system. If a server is ever down too long (configurable, default 5 minutes), the Mandos server will “disable” that server in its server list, and not provide the password to that server anymore.
The idea is that you should configure the timeout to be long enough to allow for a normal kernel panic and reboot, but hopefully short enough that it would be hard for anyone to compromise the server in that time. It’s not a perfect solution, but it’s the best anyone has come up with as far as I know.
The server itself may have been physically breached, and if so you can’t trust anything. But, if your host key matches, you should be confident that at least you’re logging into the correct machine (there was no IP takeover).
True, but in that case, I think it would still be difficult to swap in a completely new system into the network (with your IP) with your old private host key.
(Without a physical breach... if that happens, all bets are off).
What are the best options to solve this problem? It’s a hard problem imho for most threat models.
If the booting machine has been compromised and i use my usb connected keyboard to enter the full disk encryption key I would run into the exact same issues, no?
The ultrablue project I linked to solve exactly this problem, with TPM and a smartphone, but it's targeted at unlocking your laptop and uses Bluetooth to communicate with the smartphone for unlocking - and I don't want to have Bluetooth on my NAS ^^
Theoretically you could use secure boot with custom keys to ensure that your boot chain is not modified and you could use TPM for SSH host keys storage to ensure that it's not possible to copy them.
I have disk encryption on a remote server on cheap low-asssurance hosting, and I do it so I don't have to worry about what happens when the disks are recycled. If I could (easily) automate entering the key on boot, I would (but I'm running FreeBSD, so Linux solutions don't help). But I don't need to reboot often and the hardware is fairly reliable, so eh.
This is for my personal hosting which if someone wants to take over, I guess I'd be more curious than upset.
Usually I use DropBear for this. Do you know if one is necessarily better than the other? DropBear I think is what RHEL docs recommend for remote boot disk decryption.
IIUC whether that is secure depends on your threat model. For example, how good is automated unlocking compared to unencrypted drives in a homelab setup?
I guess it depends on your use case. If you rent a bunch of bare-metal servers at a remote location and you want restarts after updates to be fully automated, Clevis seems like a way to do. The whole idea is that once you cancel the server, you just remove it from Tang's list and the next customer who gets those hard drives cannot read them.
AFAICT, systemd-cryptenroll requires that you have a USB key plugged into the machine, so someone with physical access would have to insert them at the start and remove when you're done with the server. With Clevis+Tang everything is software.
The documentation for Cryptsetup SSH unlocker states “To further limit the attack possibility, you should use monitoring and possibly disable SSH unlocker in the case of unexpected behavior.” Mandos has a built-in feature to deal with this, enabled by default.
(Again, disclosure: I am the co-author of Mandos.)
Cool but something i saw that was weird, this may be the first repo i've ever seen to advertise ... words of code, i've always seen secure repos advertise their "in only X LOC" seeing words of code as a metric was funny
It's unusual, but IMO makes sense, as it encapsulates complexity better than LOC do, because the latter are more sensitive to formatting preferences etc.
Books are also measured in words too (also for category thresholds, e.g. between a novella and a full novel), so there's precedent too.
The Wren language[0] uses semicolons as its size metric:
Wren is small. The VM implementation is under 4,000 semicolons. You can skim the whole thing in an afternoon. It’s small, but not dense. It is readable and lovingly-commented.
Semicolons seems an odd metric since complexity is often introduced by if-else branches, while loops, and function declarations. Each of those doesn't involve semicolons.
I don't see anyone sensible replacing OpenSSH with anything else for two fundamental reasons:
1. OpenSSH has more eyes on it and more deployments than almost any other piece of non-OS/kernel software on the planet. By this stage in its life, it is very mature. Look at the vulnerability database, OpenSSH has not had a serious REMOTE vulnerability for a long time, all the recent vulnerabilities require the attacker to have some form of pre-existing host access (https://www.openssh.com/security.html).
2. OpenSSH comes from the house of OpenBSD. Those guys are serious about writing secure code and have a well-established track record. These days you can also compile OpenSSH against LibreSSL instead of OpenSSL.
Instead of replacing OpenSSH, most people would be better off spending their time switching OpenSSH to key-based-auth only and then making a few simple configuration changes to further harden OpenSSH. Starting with the config ideas proposed by Mozilla[1] and adding in options such as the built-in rate-limiting config options (PerSourceMaxStartups, PerSourceNetBlockSize and friends).
* “Many __informal__ eyes have probably looked at it”
* Lack of recent __number__ of (known) vulnerabilities
* “Serious guys” (appeal to authority)
I think you’re using short-hand, but perhaps the short-hand should be different. E.g.
* A list of audits by date, independent organization, is provided __here__ which is evidence of review
* The vulnerability acknowledgement, correction and release process is prompt, accurate and detailed, which is documented __here__
* XYZ coding, testing, fuzzing, proving, bounty, integration with other systems, documentation, defaults etc. practices are used in the interest in hardening the code, limiting moving parts, attack radius, etc.
Because you're the only one here trying to make the stupid argument that OpenSSH code is somehow not trustworthy.
Frankly, if you don't trust OpenSSH code for the reasons you suggest, then you should not be trusting any Operating System, whether BSD, Linux, Mac or Windows.
As I said, OpenSSH is used extensively, INCLUDING in security-critical environments, the sort of security-critical environments that you can be sure have done their homework, even if they don't publish it.
The simple fact of the matter is this:
Given the widespread global deployment of OpenSSH for DECADES now, if there were shortcomings in the code, you would have heard of it because we would be seeing BILLIONS of compromised endpoints.
Fact is, there aren't, unless you haven't bothered to update your system in the last decade.
So you can talk about fuzzing or whatever until you are blue in the face, but widespread global deployment is hard to beat, because that's REAL WORLD, failed attempts at finding zero-day exploits and all !
Well, at least it fits into GPT-4 Turbo context. I think we are not far away from a fully automated audit that can at least check for 99% of common bugs and security issues.
I don't think there's much of one. The concept in itself isn't really useful, I've never seen someone go "you know the real problem with sshd? It's too bloated".
It is slightly useful to put in smaller devices that don't have much space but I think it still relies on top many linux facilities to be an appropriate fix for that too. Still, cool project.
I suspect the average openssh-server user just uses it for remote terminal access and copying files. Reducing the attack surface by dropping features and outdated standards is certainly valuable.
There's technically no reason OpenSSHd can't also be used in this context. Maybe 2 decades ago there was a legitimate performance/disk space reason which is why Dropbear was preferred for this use case (and the convention remains to do this day), but nowadays the couple megabytes of difference in your initrd between using Dropbear and OpenSSH won't matter.
> There's technically no reason OpenSSHd can't also be used in this context.
For initrd you generally prefer static binaries. Not saying that OpenSSHd doesn't build statically, but having less code and dependencies makes it easier to statically compile.
But yes, technically there is no reason to not use OpenSSHd, but in practice having a smaller and more self contained binary helps considering that you would want the bare minimum during initrd.
dropbear has the goal of being small and light on ressources while still providing featurefull ssh support.
tinyssh is small because it only implements a tiny subset of SSH that is needed for secure basic SSH connections. It only includes few crypto primitives excluding even RSA.
There is considerable overlap in the two and you can reach something similar to tinyssh by compiling dropbear with only few select features, but tinyssh aims to be as secure and attack surface minimized as possible out of the box.
Another notable difference:
> no dynamic memory allocation - TinySSH has all memory statically allocated (less than 1MB)
> Older standard: ecdsa-sha2-nistp256, ecdh-sha2-nistp256, aes256-ctr, hmac-sha2-256 removed in version 20190101
Bah! I've soured on ed25519 because two of the tools I depend on have lackluster support.
We have one tool that leverages Macbook TouchID as a hardware keystore, and it doesn't support ed25519, only ecdsa (I don't know whether this is a TouchID or a tool limitation, I suspect tool). The other is that recent versions of Gerrit, which leverages Apache SSH, will crash the SSH connection when presented with some ed25519 certificates, which is funny since Gerrit does not support certificates!
I really wish ed25519 was more widely and better supported, or that TinySSH supported ECDSA.
- httpfile - Httpfile is an HTTP server derived from publicfile-0.52.
A collection of tiny, standard net utils and servers. Gives the impression the person does it to craft something, and to understand. Inspiring and impressive!
The device can generate a fresh keypair and show you the private key via a QR code or some other output mechanism. Then you can log in and enroll your real keys.
Is NaCl still a thing? Genuine question as I've not heard it mentioned in years.
[edit added]
For those, like me, who thought this was using Google's NaCl (sandboxed C++), it's actually using Daniel Bernstein's NaCl (cryptography library).
The copyleft trolls that Doctorow wrote about are using a termination clause in attribution-required CC licences. (Remember, there are lots of different CC licences with varying requirements on licensees.) CC0 doesn’t impose requirements on licensees nor does it have a termination clause, so it isn’t affected by these trolls.
However, CC0 is not good as a software license. It is explicitly restricted to being a copyright license. If there are patents covering the software, CC0 does not give you permission to exercise the patented invention.
It’s better to use 0BSD or MIT-0 instead, which grant permission to use the software without weird exceptions.
> It’s better to use 0BSD or MIT-0 instead, which grant permission to use the software without weird exceptions.
0BSD and MIT-0 are zero attribution ultra-permissive copyright licenses, aka public domain-equivalent copyright licenses.
CC0 is a public domain declaration with a fallback copyright license for jurisdictions (such as Germany) which don't recognise public domain declarations.
There is a big technical difference between the two, in some jurisdictions (such as the US) – CC0 puts something in the public domain, MIT-0/0BSD technically doesn't. A real difference in theory, maybe not much in practice.
If the author really cares about the public domain part, something like Unlicense is a better option than MIT-0/0BSD – an actual public domain dedication, without the patent/trademarkconcerns which exist regarding CC-0.
If they want to make the maximum possible number of people happy, they could even use disjunctive licensing, e.g. CC-0 OR Unlicense OR MIT-0
Is that necessarily a bug? If you use Disney content without a license they won't give you a 30-day period to keep mis-using it. Same with using Oracle software. Why should people who create CC content provide such a grace period?
For the reason given by Doctorow in the linked article:
If you put a CC license on your work, its explicit message is, “I want you to re-use this.” Not “I am a pedantic asshole with a fetish for well-formed attribution strings.” The point of CC is not to teach the world to write attribution strings: it is to facilitate sharing and re-use. If you are a good-faith user of CC licenses, then your response to an incorrect attribution string should be a request to correct it, not a threat to sue for $150,000 in statutory damages.
Validity of the post aside, there are real-world examples of this license being abused by third parties. Given the cost is very low to just change the license, I think it might be worth considering.
To be clear, the issue we are talking about here does not exist for the CC0 license TinySSH is using. CC0 lacks a termination clause, it wouldn't make sense for it to have one. It only exists for other CC licenses, like the (earlier versions of) CC-BY(-NC/-SA).
CC0 has other issues – some people (e.g. Red Hat Legal) are concerned about its language explicitly excluding patent and trademark rights, and think that is legally inferior to other public domain declarations (such as The Unlicense) which don't mention that topic at all.
In a declaration/license in which patents and trademarks go unmentioned, if the original author sues you on those grounds, you can try to argue that by releasing the software they gave you an implied patent/trademark license – that argument may or may not win in Court, but at least it has a chance. With language in the declaration/license explicitly excluding patents and trademarks (like CC0 has), that argument is likely dead-on-arrival.
Because people who create CC content typically do so because they want it to be available to good-faith uses, which may not always follow the exact requirements of the license by accident
In this day and age, it’s probably best to understand that blindly suggesting something should be in Rust is indistinguishable from zealotry. Or from mockery of the people who do it.
A better question to ask would have been, why settle for just memory safety - does a formally verified sshd exist? That kind of thing seems to be implemented more in OCaml and F#, like Project Everest, which has formally verified implementations of primitives (HACL) TLS, QUIC, and Signal https://project-everest.github.io/ ... ssh is notably missing?
I had a dig and found that ssh had in fact been done 9 years ago, tho it doesn't seem to have made it to a distribution: it's an offshoot of the CryptoVerif project[1] (which is, maybe unsurprisingly, under the umbrella of the same Prosecco team at Inria who worked on Project Everest). In 2015 Bruno Blanchet and David Cadé wrote a paper "From Computationally-Proved Protocol Specifications to Implementations and Application to SSH"[2] which describes using CryptoVerif to generate an implementation of SSH from the spec; the code is in the CryptoVerif tarball, but someone's helpfully put that up on github if you want a look[3]
The eye opening bits in the paper (given the claims of tinyssh to be small at < 100k words):
"We have verified that our client and server correctly interoperate with OpenSSH...in order to give an idea on the amount of code this work represents, the CryptoVerif specification amounts to 331 lines of code, and we generate from it 531 lines of OCaml, split among multiple files. The manually written code representing the primitives and the authentication and connection protocols amount to 1124 lines."
The bad news would be that it's not very performant: 30MB/s compared to 90MB/s for openssh on the same hardware, in the paper. Since HACL is from the same stable and was designed to perform well as well as be verified, it might be worth dusting off and seeing if this could be made more usable. The implementation probably has value even if just as a test oracle.
You don't need further justification if you just agree that using Rust makes everything automatically better... somehow... and you need to agree with it without evidence.
This kind of comment had become a joke these days, especially when you say that under a project written in C. Nobody is going to even think about that until Rust has as good portability as C.
I am pleased to see another "small"-is-beautifull alternative of a critical network protocol, and in plain in simple C (I am sorry for the fan boys of absurdely complex computer languages...).
There will be plenty of compiler generated holes, and other security issues, but keep your head above the water and fix all of them, you are going for the long run there.
We also have drop-bear, which is in between openssh and tinycc if I recall properly.
I have to admit... I may deploy tinyssh for my everyday work (I rarely code directly on my workstation, usually I am "away" and do ssh to it via 4g internet IPv6/ssh).
Now a bit of whining (come on, we are on HN), microsoft github is always a bad idea, should move to a fully noscript/basic (x)html friendly git repository (aka not gitlab based for instance, yet).
it's still worthwhile to point out the issues for people who have recently jumped into the occupation/hobby and haven't yet had the time to meditate on why Microsoft having the keys to the worlds' software kingdom might be A Very Bad THing down the line.
If neither GitHub nor GitLab, what are you recommending? There are a few other non-DIY hosted options, but it's hard for me to translate your "fully noscript/basic (x)html friendly" spec into an actionable list of options. Or is this a "host it yourself" / DIY plea?
Given that it's a small SSH server, I wonder how feasible it would be to rewrite it in a memory-safe language. C doesn't feel like the most security-conscious (and, quite frankly, legible) language in this day and age.
https://github.com/grazzolini/mkinitcpio-tinyssh