| 22 Apr 2025 |
 KFears (burning out) | In reply to @k900:0upti.me
As they consider the shell part of security posture I mean, SSH is literally called "secure shell"... But I think that's a very bad hill to die on tbh | 07:24:28 |
 Irenes | I'd like to hear their case in more detail, still | 07:26:24 |
| Irenes | but I'm skeptical | 07:26:31 |
| KFears (burning out) | Like, nowadays SSH is used as a remote command execution protocol in a lot of contexts. The "interactive shell" part is a lot less necessary for many uses, so it shouldn't really be the frontline anymore | 07:26:35 |
| KFears (burning out) | Because yeah that kinda sounds like log4j stance to me | 07:27:24 |
| Irenes | yes, I agree | 07:52:57 |
| Irenes | I do think I'm right, I just hesitate to fully judge their position until I've fully heard it. I've been surprised many times by things I didn't know | 07:53:25 |
| KFears (burning out) | Btw can't you supply the shell explicitly in SSH invocation? Something awful like sh -c 'echo foo; true', maybe? | 08:02:12 |
| KFears (burning out) | * Btw can't you supply the shell explicitly in SSH invocation? Something awful like /bin/sh -c 'echo foo; true', maybe? | 08:02:29 |
 K900 | In reply to @kfears:matrix.org
Btw can't you supply the shell explicitly in SSH invocation? Something awful like /bin/sh -c 'echo foo; true', maybe? But then you rely on the login shell parsing this correctly | 08:25:36 |
| KFears (burning out) | In reply to @k900:0upti.me
But then you rely on the login shell parsing this correctly You do, but login shell is giga forced into POSIX already, and I'm afraid there's no better way without patching openssh | 09:01:44 |
| KFears (burning out) | It might be better than relying on user shell, in any case... | 09:12:20 |
| K900 | In reply to @kfears:matrix.org
You do, but login shell is giga forced into POSIX already, and I'm afraid there's no better way without patching openssh My login shell is nushell | 09:22:52 |
| K900 | No regerts | 09:23:03 |
| K900 | Well | 09:23:05 |
| K900 | Evidently some regerts | 09:23:09 |
 helle (just a stray cat girl) | ssh subsystem time indeed may be a way out of this mess (and in to some others, the ssh devs made some choices in how subsystems and chroot interact, but should be fine for us, will dig up my notes on it from the last time we built one, we ended up deep diving ssh source for it) | 09:26:39 |
| K900 | It still uses the user shell AFAICT | 09:27:20 |
| K900 | So it's not a complete solution | 09:27:25 |
| helle (just a stray cat girl) | In reply to @k900:0upti.me
It still uses the user shell AFAICT yeah, that was what some of my notes are on | 09:28:59 |
| K900 | I mean it shouldn't matter if we just make it run a fixed command HOPEFULLY | 09:29:25 |
| K900 | But the problem here is that it uses the magic "started" line to check for SSH connectivity | 09:29:45 |
| K900 | Which is bad | 09:29:52 |
| K900 | I think the ideal solution is to port the whole thing over to libssh and handle errors there | 09:30:33 |
| K900 | Because that actually gives machine interpretable errors (usually) | 09:30:45 |
| helle (just a stray cat girl) | so uh, give us a moment to get started with the day and try and find the notes, we have considered submiting a patch to openssh over this mess btw.... but talk about not feeling up for the politics | 09:31:26 |
| Irenes | makes sense | 09:32:20 |
 Molly | perspective from a fly on the wall: i've got a patch for openssh in my local tree for signalling the readiness of stdio forwarding, as i have that buried deep down in some scripts i use | 09:32:43 |
| Molly | * perspective from a fly on the wall: i've got a patch for openssh in my local tree for signalling the readiness of stdio forwarding, as i rely on that deep down in some scripts i've written | 09:34:00 |
| Molly | i'm not convinced it's a good solution, but i patched the ssh client because the scripting is all for interactive usage anyway | 09:37:47 |
