TinySSH is a small SSH server using NaCl, TweetNaCl
github.com
github.com
No reason to support two ssh daemons when you can do it with one.
The difference in size on your init image is minimal and you probably aren't even trying to optimize for space there.
If you don't know the size of your rd off the top of your head then it almost certainly doesn't matter.
https://wiki.archlinux.org/title/dm-crypt/Specialties#Remote...
(Again, disclosure: I am the co-author of Mandos.)
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 :)
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.
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 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).
(Without a physical breach... if that happens, all bets are off).
This is for my personal hosting which if someone wants to take over, I guess I'd be more curious than upset.
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.
(Disclosure: I am a co-author of Mandos.)
https://access.redhat.com/documentation/en-us/red_hat_enterp...
It's fully automated and supposed to be much more secure.
Has anyone got experience with it?
Clevis+Tang is good. There's also Keylime which takes a different approach to the same[1].
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.
Or am I missing something?
https://packages.debian.org/bookworm/dropbear-initramfs https://packages.ubuntu.com/jammy/dropbear-initramfs
(Obligatory disclaimer: I am a co-author of Mandos)
Reboot your server while you sleep!
Disclosure: I am a co-author of Mandos.
Agreed.
A static tinysshd works well for the small userlands I create.
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.
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.
* https://web.archive.org/web/20240324101238/https://tinyssh.o...
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.
Yes I was using short-hand.
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 !
Is approximately one hundred thousand words really easily auditable?
According to the index page, the current release is closer to half of that at 62989 words.
Which is (allegedly, don’t trust the number too much) as long as 2001: A Space Odyssey.
https://www.readinglength.com/book/isbn-0451452739
Not a long book, but in the context of code I wouldn’t consider that easily auditable.
> TinySSH has its own crypto library
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.
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.
-passwords are not allowed, only keys
-only a single AEAD cipher is supported, and a single elliptic curve for key exchange
-root cannot be locked out with this server
-the key restrictions available in OpenSSH are not supported
-the server does not use dynamic memory, and has a better security record than dropbear
TinySSH doesnt claim to be compliant, and isnt. Does less in exchange for a reduced attack surface.
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.
- tinyssh - TinySSH is a small server with less than 100,000 words of code. Language: C. Stars: 1.1k. Forks: 65.
- acmeshell - Shell-style client for LetsEncrypt. Language: Python. Stars: 31. Forks: 6.
- dq - Recursive DNS/DNSCurve server and command-line tool to debug DNS/DNSCurve. Language: C. Stars: 23. Forks: 1.
- pstree - Unix process tree viewer. Language: C. Stars: 14. Forks: 2.
- ntpserver - Pure python NTP server. Language: Python. Stars: 11. Forks: 3.
- 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!
I guess perhaps to you they would.
But why don’t you check it out rather than writing a silly comment?
I use dqcache, the DNSCurve-aware recursive resolver from the dq package, and love it.
tinysshd doesn't implement unsafe features (such as password or hostbased authentication)
[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).
In light of this post outlining a bug in early CC licenses: https://doctorow.medium.com/a-bug-in-early-creative-commons-...
Discussed here: https://news.ycombinator.com/item?id=39610509
Does this need updating?
EDIT: based on some discussion, it does need updating, but not for the reason I thought. I filed a suggestion here: https://github.com/janmojzis/tinyssh/issues/85
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.
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.
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.
If author/maintainer doesn't frequent HN, perhaps discussion there might get some action.
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
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).
Codeberg has a message that says "This website requires JavaScript." but I was able to use it without JS to browse around and look at code properly.