TOR class to allow remote SSH access over deep networks

[anarcat]

This class configures an onion service to access the SSH server over Tor. This is useful when you have a box behind NAT or some firewall that is broken or unknown, and you need to get a rescue shell on the host.

With this, you give an operator a thumb drive, who only needs to figure out how to boot into GRML, and then after a while you get a shell, pretty much regardless of where the box is.

This is not enabled by default, naturally, otherwise the secret key would leak in default GRML builds: this is solely designed to be run in an ad-hoc, one-time fashion. It also generates the SSH keys for the same reason: those are shown in the build logs and can be used to authenticate the remote host (a redundant measure to the onion service name, of course).

I also enable DEFAULT_BOOT_OPTIONS=ssh in my builds, but that hasn't been done here (although maybe it's possible to enable that in the class? to be investigated).

Finally, another shim is required here to inject a valid SSH public key in the image, so you can login over SSH. In my case, I have an extra CLASS that only has this one script which does:

gpg --export-ssh-key [email protected] | tee -a $target/root/.ssh/authorized_keys

This could also be folded in the TOR class, but I'm not sure how to do variables yet, so that's not yet standardized.

[anarcat]

This probably needs docs and maybe a built-in way to enable ssh and an authorized_keys by default, but I'd like to hear if it's useful from the team before going any further.

[zeha]

Obvious things first:

1. this needs a rebase, sorry
2. we can't merge the DEFAULT_BOOTOPTIONS change as is, as it would apply to all builds. Maybe that should go into a readme for the class.

[anarcat]

we can't merge the DEFAULT_BOOTOPTIONS change as is, as it would apply to all builds. Maybe that should go into a readme for the class.

what would go in the README here actually? something like "you also need the ssh boot option in .live.local"?

[zeha]

we can't merge the DEFAULT_BOOTOPTIONS change as is, as it would apply to all builds. Maybe that should go into a readme for the class.

what would go in the README here actually? something like "you also need the ssh boot option in .live.local"?

yeah. and/or "you need to set DEFAULT_BOOTOPTIONS=ssh" when invoking grml-live.

Also I think the text from the PR description would also be useful in that readme.

[zeha]

@mika I assume we'd be fine merging this in principle. Do you agree?

[anarcat]

Also I think the text from the PR description would also be useful in that readme.

so for now i've thrown together a blurb about the new class in grml-live(8) since I couldn't find an example of where i would put a README for the class. it's a bit verbose, but then there's stuff to be said... ;)

this needs a rebase, sorry

done!

@mika I assume we'd be fine merging this in principle. Do you agree?

this is why this is still a draft and i haven't put much effort into it: i wasn't sure if it's something you'd be interested in!

but the version i originally sent here mostly works for my purposes... i had to add another class (which i called GPG_SSH) that throws in my SSH pubkey so that i can actually login the booted system as well:

--- /dev/null
+++ b/etc/grml/fai/config/scripts/GPG_SSH/10-export-ssh
@@ -0,0 +1,4 @@
+#!/bin/sh
+
+echo "deploying [email protected] SSH key to $target"
+gpg --export-ssh-key [email protected] | tee -a $target/root/.ssh/authorized_keys

... which makes me think that, maybe, there's a separate SSHGEN class that could spun off here where you generate the SSH keys (just like you generate the onion keys) and inject a pubkey for the operator... and it's kind of orthogonal to the TOR stuff, and could be spun out..

so that's also something i'd welcome feedback on! :)

thank you so much for reviewing this old PR!

[zeha]

as discussed on irc: if the assumption is people would use this mostly with ssh keys, then i think the script can just enable ssh.service (vs. documenting to set the ssh boot option).

[anarcat]

as discussed on irc: if the assumption is people would use this mostly with ssh keys, then i think the script can just enable ssh.service (vs. documenting to set the ssh boot option).

so that's the assumption, and i've tried to do that in https://github.com/grml/grml-live/pull/146/commits/b645580da653bddee39aecf860ea0ec64acb47a8, but i didn't like it: just enabling the service is the easiest part of the problem to fix. as i mentioned in https://github.com/grml/grml-live/pull/146#issuecomment-3365771438, the harder part of the problem is the more complex question of "how do i inject SSH keys in the image", and for that there are already plenty of answers in GRML itself, which we suggest in the manual.

that said, i'd still love to see a trick to inject my public key into an image at build time without hardcoding it in the script... but i don't think there's an easy way to do that short of starting to teach people how to hack at FAI...

[zeha]

@mika will wait for your +2

[mika]

@mika I assume we'd be fine merging this in principle. Do you agree?

absolutely!

[anarcat]

cool! i can't actually merge this, in case you were wondering. ;)