| 22 Apr 2025 |
 Molly | (https://skarnet.org/software/s6/notifywhenup.html is what i was aiming for, but passing file descriptors around with the ssh client is a bit fiddly with how proactively openssh locks everything down, so i've implemented it with some socket fd passing) | 09:42:23 |
 K900 | Honestly I wonder if the real solution for this is to just do capnp over mTLS or something | 09:42:58 |
| Molly | ssh has the advantage that it's already there in most cases and already has its own authn/authz in place | 09:45:06 |
 Irenes | it does feel like tls or mtls with mutual authentication would be the better solutions to a lot of things ssh gets used for | 09:45:08 |
 Qyriad | In reply to @k900:0upti.me
My login shell is nushell this kind of thing is why we set our login shell to zsh and just make all our terminal emulators spawn xonsh lol | 09:45:19 |
| Irenes | but I understand wanting to leverage existing, well-understood stuff | 09:45:25 |
| K900 | Yes, and the disadvantage that we're using it for the exact thing they DON'T want people doing | 09:45:28 |
| Molly | mmm | 09:45:53 |
| Molly | there's some prior art for using a separate ssh subsystem for other use cases, i seem to recall the RPKI routing security stuff uses a separate subsystem when using ssh as a transport | 09:47:14 |
 helle (just a stray cat girl) | In reply to @molly:161.rocks
there's some prior art for using a separate ssh subsystem for other use cases, i seem to recall the RPKI routing security stuff uses a separate subsystem when using ssh as a transport yeah, openssh really wants people to consider subsystems for this | 09:48:11 |
| Molly | (which i presume is a result of one of the big players who's pushed the rpki stuff forward also being openbsd and openssh adjacent) | 09:48:14 |
| helle (just a stray cat girl) | btw for me the reasoning for wanting to stick with ssh for this is, it already has good auth* and not exposing more of an attack surface for that | 09:48:54 |
| Molly | openssh is also something which people know already, which may or may not be a useful property | 09:49:33 |
| Molly | (i should make it clear that i don't have a horse in this race, i just saw the conversation go past and it sparked my interest >_>) | 09:49:54 |
| Irenes | yeah doing auth right is hard | 09:50:15 |
| Irenes | or at least, it requires planning | 09:50:43 |
| helle (just a stray cat girl) | I only have one because of implementing subsystems and even chrooting them before, anyway, brb, need to consume breakfast and all that before we can dig up the notes, lol | 09:51:05 |
| Molly | (now that i've mentioned that, the bird routing daemon also decided to use libssh for accessing rpki data sources over an ssh transport) | 09:53:43 |
 KFears (burning out) | In reply to @k900:0upti.me
Honestly I wonder if the real solution for this is to just do capnp over mTLS or something I mean, honestly, yes | 10:58:27 |
| KFears (burning out) | But it's not yet | 10:58:40 |
| helle (just a stray cat girl) | okay, going over this and looking at our notes, in all cases even for Subsystem, sshd will always use the user's login shell as it currently stands, fixing this on the ssh side at least for subsystems would be surprisingly trivial (we had considered doing this when running into an issue with chrooting and securing ssh), but let's ignore that for now (yeah, we are scared to contribute code anywhere)
all shells, no matter how otherwise limited at being posix do seem to support "-c" and hence ssh running a remote command does work, just you cannot rely on anything but launching an executable, because of shell feature difference
the simple solution hence would be to make nix-daemon launchable as simple as possible and include a way to let it produce the "started" (technically a user could use a wrapper script for this), you could even consider not needing arguments to do this, so even the most rudimentary argument parsing does not need to work
we would actually say that print "started" should probably still be the case (communicating that "yes, you are connected to a working nix-daemon) even if we replace calling ssh with using libssh, because the shell may have mangled setup, etc so having a clear way of detecting we are actively communicating makes sense
relatedly, if there are issues specifically to stdio we could instead use port forwarding to forward a unix socket instead, this is reliable and avoids the inband nature of the shell potentially giving us output on stdout that we don't know how to handle | 12:59:37 |
 piegames |
sshd will always use the user's login shell as it currently stands
👀 Is there really no unintrusive way around this?
| 13:02:07 |
| piegames | This sounds so bad yet sadly plausible | 13:03:03 |
| helle (just a stray cat girl) | In reply to @piegames:flausch.social
sshd will always use the user's login shell as it currently stands
👀 Is there really no unintrusive way around this?
nope, we ran into this hard, we tried everything and read the entire code on how commands, ForceCommand, Subsystem, etc works | 13:03:41 |
| helle (just a stray cat girl) | even ForceCommand (and hence Subsystems) rely on the user having a login shell, it is why git-shell exists to hand accounts as a login shell if they only should be doing git things | 13:14:50 |
| helle (just a stray cat girl) | oh, from the manpage, yes "If a command is specified, it will be executed on the remote host instead of a login shell." is a total lie | 13:19:37 |
| K900 | I spoke to horrors a bit | 13:21:00 |
| K900 | And I'm starting to be convinced that we can just drop the "started" hack | 13:21:16 |
| K900 | It's a band-aid for a very specific failure mode | 13:21:32 |
| K900 | That you're also wildly unlikely to hit | 13:21:40 |
