TOR class to allow remote SSH access over deep networks #146
Conversation
|
This probably needs docs and maybe a built-in way to enable |
anarcat
force-pushed
the
TOR
branch
2 times, most recently
from
7cf973c to
017064b
Compare
anarcat
force-pushed
the
TOR
branch
2 times, most recently
from
24d33ee to
d51fc3d
Compare
|
Obvious things first:
|
what would go in the README here actually? something like "you also need the |
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. |
|
@mika I assume we'd be fine merging this in principle. Do you agree? |
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... ;)
done!
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 --- /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! |
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 assumes something else manages the SSH service, which will be done in a separate SSHGEN class.
|
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 |
anarcat
force-pushed
the
TOR
branch
2 times, most recently
from
088e3c4 to
61f2b5a
Compare
so that's the assumption, and i've tried to do that in b645580, but i didn't like it: just enabling the service is the easiest part of the problem to fix. as i mentioned in #146 (comment), 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... |
|
@mika will wait for your +2 |
absolutely! |
This also moves the ssh configuration there instead of hardcoding it.
This class enables the SSH service and generates SSH keys for the same
reason as the TOR class generating onion service keys: 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).
It also enables the SSH service, roughly equivalent to passing the
`ssh` boot option.
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 SSHGEN class, but I'm not sure how to
do variables yet, so that's not yet standardized.
This is just a bad idea: it doesn't actually do all that we need, which is to inject a public key in the built image. Instead, it's best to teach people about the ssh boot option and encpasswd, which are sufficient for this case. This reverts commit b645580.
Here we take the approach of not doing anything fancy with SSH out of the ordinary: we tell grml to boot with the ssh option and pass a secret password or a netconfig= fetch at build time. We pick this approach instead of adding another class because we can't quite tell how to easily pass a SSH public key to an eventual SSHGEN class.
|
cool! i can't actually merge this, in case you were wondering. ;) |
3 participants
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=sshin 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:
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.