[08:41:37] volans: You can have a jump host with no shell access, then it matters LESS that you jump as root [09:10:42] slyngs: how would you do that? Setting a command=? I've seen for example https://gist.github.com/smoser/3e9430c51e23e0c0d16c359a2ca668ae but needs a user anyway [09:11:26] You need the user, but the shell can just be /bin/true [09:12:55] Let me just look, I think I saw an example some time ago [09:15:45] Okay, yeah so like the example you posted, the just use an echo for the ForceCommand, and not true [09:15:53] Would that not work? [09:16:34] You could also set MaxSessions to zero I think [09:18:08] Something like: [09:18:12] https://www.irccloud.com/pastebin/hXjLkj5r/ [09:20:10] Specifies the maximum number of open shell, login or subsystem (e.g. sftp) sessions permitted per network connection. Multiple sessions may be established by clients that support connection multiplexing. Setting MaxSessions to 1 will effectively disable session multiplexing, whereas setting it to 0 will prevent all shell, login and subsystem sessions while still permitting forwarding. The default is 10. [09:21:29] Or maybe I'm misunderstanding the issue [09:35:54] slyngs: the problem was to not create a dedicated user [09:36:27] once we have a user that has no privileges there is no need for any further hardening as all the users of coudcumin* will have already access to the bastions as unpriviliged users [09:36:53] *"problem" [09:37:19] it's just that we'll be using the bastion in the opposite direction as it's usually used [09:46:49] In that case I think I'd just create the dedicated user, rather than deal with Squid and the added complexity. [09:49:18] You could also use haproxy, which seems like a better choice that Squid, given the task [09:49:24] than [09:57:13] eh, just to simplify things :) [10:04:47] Again, I may very well completely misunderstand the issue. Adding Squid to the mix just rarely makes things better, unless you need and http proxy, in which case it's a fine choice :-) [10:06:09] slyngs: we already have squid proxies for outbound (prod->internet) traffic [10:06:26] https://wikitech.wikimedia.org/wiki/HTTP_proxy [10:06:29] Aaah [10:12:31] I'm not suggesting it as something that one would actually do but... you can ram SSH through an http proxy http://www.nazgul.ch/dev/gotthard_man.html [11:31:03] slyngs: in you example we cant set the shell of root to /bin/true so we would still need to create a seperate user unless im missing something, however this honestly seems more complicate then adding a few lines to the squid config, also im not sure we need to use gotthard, we can just use "ProxyCommand nc --proxy webproxy:8080 %h %p" [11:32:54] No no, you'd still need the user. I think point I'm missing is why a new user is more complicated than using Squid. The Gotthard thing is not something I'd recommend, I just love that it exists [11:40:09] to me the case for squid is that it is the current egress for production servers, with monitoring and metricts, so in the spirit of KISS it make senses to continue to use that as the egress point instead of createing a new solution just for this use case and protocol. futher in the spirit of least privalage access why create an account to a production host wthat will ultimatly be [11:40:15] exposed to community members if we dont need to [11:49:27] Fair point :-) I do think it's sort of confusing to in this one place, SSH traffic is suddenly routed via Squid. I don't know, my argument in the same KISS spirit is that the added user is easier to understand solution. Anyway, I was just interested, but there's a bunch of details I still don't understand about our intrastructure [12:20:03] jbond: "ultimatly be exposed to community members" ? [12:22:15] jbond: any user that will have access to the cloudcuminNNNN hosts will also have access to the bastions [12:22:21] XioNoX: i belive that the desire is for cummunity memberes to be able to use cloudcumin hosts to manage wmcs infrastructre. as such in time (trusted) community memberes will be able to ssh into cloudcuminNNNN and use the bath we decide here to connect to cloud production serveres (openstack infra) and WMCS VMs (cc volans) [12:22:33] thats true [12:22:34] so I don't see any concern there, theu will have access as their own user + the dedicated user for ssh jump [12:23:11] FTR i dont have a peticuly strong view either way but a minor leaning towards squid [12:23:15] and yes the end goal is that but there is a full task that we're preparing with security concerns for that that will need to be addressed before that's possible [12:23:27] if that works I don't mind using squid [12:23:29] fyi i think this would be the squid patch https://gerrit.wikimedia.org/r/c/operations/puppet/+/868372 [12:24:17] probably needs a bit of polishing but will leave it there untill there is a decition [12:27:47] thanks! I'll have a look after lunch