--- Log opened Fri May 10 00:00:17 2024 |
00:10 | | Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has quit [Ping timeout: 121 seconds] |
01:23 | | Vornicus [Vorn@Nightstar-8k6f0b.res.spectrum.com] has quit [Connection closed] |
04:27 | | Degi [Degi@Nightstar-8mhk9r.pool.telefonica.de] has quit [Ping timeout: 121 seconds] |
04:28 | | Degi [Degi@Nightstar-rn3h8l.pool.telefonica.de] has joined #code |
08:29 | <@mac> | If there's anyone here who's good with Docker, SSHD, networking, and/or the esoterica of Linux user management, I have a couple questions I could use some help on: |
08:29 | <@mac> | https://stackoverflow.com/questions/78453540/configure-sshd-running-in-a-docker-container-to-only-accept-logins-to-a-certain |
08:29 | <@mac> | https://stackoverflow.com/questions/78458629/persists-users-added-within-a-docker-container |
09:52 | | Kimo|autojoin [Kindamoody@Nightstar-b96ksk.mobileonline.telia.com] has joined #code |
09:52 | | mode/#code [+o Kimo|autojoin] by ChanServ |
09:58 | <&[R]> | Sure, let me take a look |
09:59 | <&[R]> | mac: I would honestly use self-signed certificates for this |
09:59 | <&[R]> | s/self-signed/CA/ |
09:59 | <&[R]> | Then block all non-CA certs |
10:00 | <&[R]> | When you sign a key, you can set it so that key can only run a specific command, which can reduce your attack surface, you can also set the keys to expire. |
10:00 | <&[R]> | (I'm a little loopy due to not being able to sleep, so you might have to bear with me) |
10:02 | | [R] [rms@Nightstar-d7h8ki.org] has quit [The TLS connection was non-properly terminated.] |
10:03 | | [R] [rms@Nightstar-d7h8ki.org] has joined #code |
10:03 | | mode/#code [+ao [R] [R]] by ChanServ |
10:03 | <&[R]> | FFS |
10:03 | <&[R]> | mac: I sent 6 messages, did they all come through? |
10:03 | | Kimo|autojoin is now known as Kindamoody |
10:04 | <@mac> | [R]: Last I saw was [05:00:53] <[R]> (I'm a little loopy due to not being able to sleep, so you might have to bear with me) |
10:04 | <&[R]> | Cool, they all came through |
10:04 | <@mac> | [05:00:53] <[R]> (I'm a little loopy due to not being able to sleep, so you might have to bear with me) |
10:04 | <@mac> | [R]: I don't see how CAs would help. Every device that's connecting already has its own different SSH key it uses to do so. The problem is, while you can restrict what /commands/ a given key can access, the ability to forward socket files is, AFAICT, all-or-nothing. If a given key is permitted to do socket forwarding, then it can create a socket anywhere the user it is logged in as has write permissions. |
10:06 | <&[R]> | Yeah, you can also specify port forwarding options (IE: access to a socket), then disable port forwarding when you sign the key |
10:06 | <&[R]> | This 1) enables that port forward 2) prevents them from being able to apply more |
10:08 | <&[R]> | You can also limit what source address the key is valid for |
10:08 | | KiMo|autorejoin [Kindamoody@Nightstar-b96ksk.mobileonline.telia.com] has joined #code |
10:08 | | Kindamoody [Kindamoody@Nightstar-b96ksk.mobileonline.telia.com] has quit [Connection reset by peer] |
10:08 | <&[R]> | Though it looks like the port forwarding thing wasn't correct |
10:09 | <&[R]> | So I would instead force a command that gives them a pipe to the correct socket file instead |
10:09 | <&[R]> | Unless you need special unix-socket side-channel stuff? |
10:09 | <@mac> | [R]: Huh. I'll have to check that out. Honestly, I was surprised there /wasn't/ an option to control which sockets a user is allowed to forward (there is an option to restrict which TCP ports that can forward, but not which sockets), so it seems odd that such a facility would be available via key-signing but not via sshd_config. |
10:10 | | * [R] likes key signing in general for SSH deployments TBH |
10:11 | <&[R]> | Because you can use it to set settings they can't muck with |
10:11 | <&[R]> | Without having to edit the sshd_config file all the time |
10:12 | <&[R]> | If you're using force-command you need to provide a key per command though. |
10:12 | | * [R] scripts the generation and signing of keys |
10:13 | <&[R]> | Do you need special unix socket stuff? |
10:14 | <&[R]> | Or can you work with just a pipe? |
10:16 | | [R] [rms@Nightstar-d7h8ki.org] has quit [Connection closed] |
10:16 | | [R] [rms@Nightstar-d7h8ki.org] has joined #code |
10:16 | | mode/#code [+ao [R] [R]] by ChanServ |
10:16 | <&[R]> | WTF |
10:17 | <@mac> | [R]: My use case in more detail: each remote machine is running a webserver that listens on port 8010. (Localhost only; not accessible from the web.) The device does `ssh -R "/sockets/${DEVICE_ID}/scanner.sock:localhost:8010" -N my_dockerized_sshd_server`. '/sockets/' is a Docker volume which multiple containers mount. Processes in other containers send HTTP requests to `/sockets/${DEVICE_ID}/scanner.sock` and, like magic, these requests end up at |
10:17 | <@mac> | the webserver on the device. |
10:18 | <&[R]> | Okay, so the ssh clients are providing their local webserver as a socket? |
10:18 | <@mac> | Yes. |
10:20 | <&[R]> | Okay, that gets a little iffy with the ncat method |
10:23 | <@mac> | Just double-checked the online manpage; CA signing doesn't offer any restrictions on what the key can be used for that can't already be implemented directly in 'authorized_keys' or 'sshd_config'. |
10:23 | <&[R]> | Yeah |
10:27 | <@mac> | Annoyingly, if I were doing TCP forwarding, I absolutely /can/ specify which TCP ports you're allowed to forward, on a per-key basis in the 'authorized_keys' file. |
10:27 | <&[R]> | Yeah |
10:27 | <&[R]> | Are they all using the same user account? |
10:29 | | Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has joined #code |
10:30 | <@mac> | [R]: That's what's up for debate, isn't it? My first implementation had one user account in the SSHD container, `ssh_in`, which accepted connections from every device. I switched to using a different user account for each device specifically so that I could control where they were able to create their socket files - but then I have the problem of persisting user account that were not created in the Docker build phase. |
10:36 | <&[R]> | "A related feature was added to support the Unix domain-socket forwarding. The escape sequence %C can be used in both the LocalCommand and ControlPath arguments of a configuration file. It expands to a unique identifier derived from the SHA-1 hash of (local host, remote user, hostname, port). The other escape sequences (such as %h for remote hostname and %u for local username) are often used with the expectation that, when expanded, they will comprise a unique id |
10:36 | <&[R]> | Hmmmm |
10:37 | <&[R]> | Actually that might not be helpful |
10:39 | | KiMo|autorejoin [Kindamoody@Nightstar-b96ksk.mobileonline.telia.com] has quit [Ping timeout: 121 seconds] |
10:40 | <@mac> | [R]: No, I don't think it is. Nothing on the SSH end can possibly be; if the client is cooperating, I've already got a unique ID - the device serial number - which I can use in the socket file. What I need is something on the SSHD end to make it so a misbehaving client can't clobber somebody else's socket file. |
10:40 | <&[R]> | Yeah |
10:41 | <&[R]> | Can't really do the pipe thing, since the listening socket is on the sshd side |
10:41 | <&[R]> | Which would actually make this so much easier |
10:45 | | * mac eyes the time |
10:46 | <@mac> | I need to enbedenate |
10:46 | <&[R]> | NN |
10:46 | <@mac> | Ni! |
14:09 | <@celticminstrel> | enbedenate |
14:09 | <@celticminstrel> | XD |
14:10 | <@celticminstrel> | (Mispelled tho. Should be embedinate.) |
14:12 | <@celticminstrel> | (No wait. Don't you need to double the D to keep the E short?) |
14:13 | <@celticminstrel> | (Some research indicates thet -enate is correct after all, so final spelling is embeddenate.) |
14:15 | <@celticminstrel> | (Huh, apparently "embed" actually lists that meaning on Wiktionary as its first meaning. I've never actually heard it used that way tho.) |
14:15 | <@celticminstrel> | (Ah, not quite, it's "as in a bed" not "actually in a bed"… still…) |
14:42 | | Vornicus [Vorn@Nightstar-8k6f0b.res.spectrum.com] has joined #code |
14:42 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
16:26 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [The TLS connection was non-properly terminated.] |
16:29 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code |
16:29 | | mode/#code [+o PinkFreud] by ChanServ |
17:43 | | Kimo|autojoin [Kindamoody@Nightstar-157k7j.mobileonline.telia.com] has joined #code |
17:43 | | mode/#code [+o Kimo|autojoin] by ChanServ |
18:36 | | Vornicus [Vorn@Nightstar-8k6f0b.res.spectrum.com] has quit [Connection closed] |
19:41 | | Kimo|autojoin is now known as Kindamoody |
19:52 | | Kindamoody [Kindamoody@Nightstar-157k7j.mobileonline.telia.com] has quit [Ping timeout: 121 seconds] |
20:05 | | McMartin [mcmartin@Nightstar-n6bm7f.sntcca.sbcglobal.net] has joined #code |
20:05 | | mode/#code [+ao McMartin McMartin] by ChanServ |
22:01 | | JustBob [justbob@Nightstar.Customer.Dissatisfaction.Administrator] has quit [Ping timeout: 121 seconds] |
23:16 | | Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has quit [Ping timeout: 121 seconds] |
23:49 | | PinkFreud [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [The TLS connection was non-properly terminated.] |
--- Log closed Sat May 11 00:00:18 2024 |