TinySSH is a small SSH server using NaCl, TweetNaCl

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.

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?

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

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.

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

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

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

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.

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.

Probably not more popular because (for reasons I do not know) the mkinitcpio hooks Arch Linux provides are only for tinyssh and dropbear:

https://wiki.archlinux.org/title/dm-crypt/Specialties#Remote...

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/

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've seen a bit about Clevis. Is there a major difference between using this, and systemd-cryptenroll?

Note: Mandos is also in Debian and Ubuntu.

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

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

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

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

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

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.

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.

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

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

I copied your comment to https://github.com/janmojzis/tinyssh/issues/85

If author/maintainer doesn't frequent HN, perhaps discussion there might get some action.

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

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.

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

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.

I think they're both pretty reasonable questions!

Maybe M-x count-words?

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.

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.

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.

How?

I guess perhaps to you they would.

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

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 !