return to table of content

TinySSH is a small SSH server using NaCl, TweetNaCl

bretthoerner
34 replies
1d5h

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.

https://github.com/grazzolini/mkinitcpio-tinyssh

forty
14 replies
1d4h

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 :)

[1] https://github.com/ANSSI-FR/ultrablue

bretthoerner
3 replies
1d4h

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.

jethro_tell
2 replies
23h20m

This is mostly me but the case that's the most common is that a disk can't be wiped because its dead. Gotta do that before hand.

aftbit
1 replies
21h50m

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.

jethro_tell
0 replies
3h0m

That doesn't work if you need to RMA the disk. So best to encrypt before you put anything on the disk

rand846633
2 replies
1d2h

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?

vbezhenar
0 replies
6h0m

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.

fbdab103
0 replies
1d

If you have physical access, seems way easier to put a keylogger directly into the keyboard.

mbreese
1 replies
1d

Isn’t there a host SSH key involved?

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

akerl_
0 replies
17h6m

If the server was breached, what stops somebody from copying the host key to their new system.

toast0
0 replies
1d

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.

teddyh
0 replies
20h52m

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.

(Disclosure: I am a co-author of Mandos.)

pmorici
0 replies
1d2h

TPM and checking your physical security boundary hasn't been breached.

jsmith99
0 replies
1d2h

This is what a TPM is designed to prevent, but they’re not very popular in Linux community.

crote
0 replies
23h52m

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.

jethro_tell
3 replies
1d4h

I use normal opensshd for this.

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.

bretthoerner
1 replies
1d4h

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.

jethro_tell
0 replies
23h22m

Makes sense. Probably more work to go off the beaten path then to maintain two configs

traceroute66
0 replies
1d1h

I thought that everyone has switched to Clevis + Tang for that?

Clevis+Tang is good. There's also Keylime which takes a different approach to the same[1].

[1] https://keylime.dev/

soraminazuki
0 replies
1d1h

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?

ahepp
0 replies
18h31m

I've seen a bit about Clevis. Is there a major difference between using this, and systemd-cryptenroll?

teddyh
0 replies
20h59m

Note: Mandos is also in Debian and Ubuntu.

(Obligatory disclaimer: I am a co-author of Mandos)

justin_oaks
0 replies
22h54m

I've used this for several years now. It works well and is relatively easy to set up.

teddyh
1 replies
23h46m

There’s a non-interactive solution to rebooting safely with encrypted disks: Mandos <https://www.recompile.se/mandos>

Reboot your server while you sleep!

Disclosure: I am a co-author of Mandos.

jethro_tell
0 replies
23h23m

This is really cool. I'm going to give this a try!

teddyh
0 replies
21h4m

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

gymbeaux
1 replies
1d5h

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.

bretthoerner
0 replies
1d4h

Ah, I've never used DropBear. I don't know how one could be better than another for my simple use case, honestly.

1vuio0pswjnm7
0 replies
14h34m

"tinyssh is great."

Agreed.

A static tinysshd works well for the small userlands I create.

k8sToGo
13 replies
1d8h

What is the difference between this and dropbear ssh?

themoonisachees
7 replies
1d8h

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.

maxcoder4
5 replies
1d7h

Dropbear ssh is very useful when you have a full disk encryption on a remote server and want to be able to decrypt it after a reboot.

Nextgrid
4 replies
1d7h

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.

m45t3r
3 replies
1d4h

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.

akerl_
2 replies
1d4h

What dependencies does openssh have?

mkj
1 replies
1d3h

OpenSSL

1oooqooq
0 replies
1d1h

if you don't care for v1 and odd cyphers, --without-openssl

dhon_
0 replies
1d7h

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.

Columbo818
1 replies
1d7h

Dropbear claims to be RFC-compliant, but isnt. Proof here: https://www.cvedetails.com/cve/CVE-2021-36369/

TinySSH doesnt claim to be compliant, and isnt. Does less in exchange for a reduced attack surface.

mkj
0 replies
1d3h

That CVE is a UI confusion issue in the client, I'm not sure exactly what bit the reporter thought was non-RFC compliant.

chasil
0 replies
1d7h

This server is very restricted compared to dropbear.

-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

bjoli
0 replies
1d7h

It is smaller and supports less features. Dropbear does password auth and x11 agent forwarding iirc.

ThreeHopsAhead
0 replies
1d7h

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)
fanf2
5 replies
1d4h

Not for that reason.

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.

makeworld
1 replies
1d3h

0BSD and MIT-0 don't mention patents explicitly though, few licenses do. I only know of two: https://blueoakcouncil.org/list

fanf2
0 replies
1d3h

They don’t mention copyright explicitly either.

skissane
0 replies
22h59m

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

gkbrk
4 replies
1d4h

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?

jvanderbot
1 replies
1d4h

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.

skissane
0 replies
23h0m

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.

saagarjha
0 replies
1d4h

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

jasomill
0 replies
1d4h

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.

CarRamrod
7 replies
1d7h

easy auditable - TinySSH has less than 100000 words of code

Is approximately one hundred thousand words really easily auditable?

tptacek
1 replies
1d4h

Seems like the wrong question. Rather: if it's easily auditable, who's audited it so far?

loeg
0 replies
1d

I think they're both pretty reasonable questions!

nemoniac
1 replies
22h6m

What is a "word of code"? I've seen "lines of code" but what's a "word" in C?

teddyh
0 replies
21h2m

Maybe M-x count-words?

rthnbgrredf
0 replies
1d6h

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.

latexr
0 replies
1d7h

approximately one hundred thousand words

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.

edf13
0 replies
1d5h

Not really, especially when they have:

TinySSH has its own crypto library
cchance
5 replies
1d3h

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

fbdab103
2 replies
1d

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.
[0] https://wren.io/

justin_oaks
1 replies
22h43m

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.

genezeta
0 replies
5h56m

I don't know, but it might be somewhat tongue-in-cheek since Wren itself doesn't use semicolons at all.

oxryly1
0 replies
1d2h

Made it seem like it was written in Forth.

creshal
0 replies
1d3h

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.

sylware
4 replies
1d6h

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

pquki4
1 replies
1d5h

You are fighting a losing battle if you don't want to see GitHub links on HN.

serf
0 replies
1d5h

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.

jonathaneunice
1 replies
1d4h

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?

gkbrk
0 replies
1d4h

Soucehut works with noscript. No need to host or DIY anything.

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.

keepamovin
3 replies
1d3h

I like this person's work. Check it out:

https://github.com/janmojzis

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

1oooqooq
1 replies
1d1h

some of those look like spoofs?

keepamovin
0 replies
14h38m

How?

I guess perhaps to you they would.

But why don’t you check it out rather than writing a silly comment?

Panino
0 replies
1d

dq - Recursive DNS/DNSCurve server and command-line tool to debug DNS/DNSCurve

I use dqcache, the DNSCurve-aware recursive resolver from the dq package, and love it.

traceroute66
2 replies
1d1h

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

[1] https://infosec.mozilla.org/guidelines/openssh

wibblewobble125
1 replies
20h52m

Bad reasons to trust code:

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

traceroute66
0 replies
18h58m

I think you’re using short-hand

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 !

numpad0
2 replies
1d5h

  tinysshd doesn't implement unsafe features (such as password or hostbased authentication)
Isn't password support useful for shared devices, like printers and routers? How would one enroll his personal keys on something like a car?

rstat1
0 replies
12h24m

You wouldn't, because you wouldn't be SSH'ing in to a car. I would hope such things wouldn't even be possible.

Retr0id
0 replies
1d5h

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.

vzaliva
1 replies
1d1h

It looks like a good choice for access to small embedded devices. Except the missing port forwarding feature.

itpcc
1 replies
1d8h

Poor, poor site. They got HN hug of death.

Brian_K_White
0 replies
1d

I can only assume it's idiots downvoting this, who think you are bashing the site instead of sympathising with it.

zoobab
0 replies
7h24m

I would have redone in ZeroMQ+CurveCP, probably way less lines of code since most of what you need should be already there.

yodon
0 replies
1d4h

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

rand846633
0 replies
1d7h

Cool project! There are many use cases where this is a good tool! Allways great to have another alternative to some other great tools.

aAaaArrRgH
0 replies
23h5m

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.

Hendrikto
0 replies
1d4h

Shame that it does not support ed25519-sk. Apart from that, it looks very promising.

AceJohnny2
0 replies
17h0m

State-of-the-art crypto: ssh-ed25519, curve25519-sha256, chacha20-poly1305@openssh.com

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.