IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 12 October 2015 (all times are UTC)
| 00:00 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 01:33 | StolenToast has left IRC (StolenToast!~stolentoa@cnut.resist.cc, Ping timeout: 264 seconds) | |
| 01:42 | StolenToast has joined IRC (StolenToast!~stolentoa@cnut.resist.cc) | |
| 01:47 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection) | |
| 01:48 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 01:52 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection) | |
| 02:11 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 02:15 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 246 seconds) | |
| 03:11 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 03:16 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 255 seconds) | |
| 03:22 | fnurl has joined IRC (fnurl!3cf8605f@gateway/web/freenode/ip.60.248.96.95) | |
| 04:13 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 04:18 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 264 seconds) | |
| 05:15 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 05:20 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 264 seconds) | |
| 05:25 | alkisg has left IRC (alkisg!~Thunderbi@ubuntu/member/alkisg, Remote host closed the connection) | |
| 05:27 | alkisg has joined IRC (alkisg!~Thunderbi@ubuntu/member/alkisg) | |
| 05:42 | yanu has left IRC (yanu!~yanu@178-116-58-90.access.telenet.be, Quit: leaving) | |
| 05:43 | yanu has joined IRC (yanu!~yanu@178-116-58-90.access.telenet.be) | |
| 06:16 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 06:21 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 256 seconds) | |
| 06:30 | ricotz has joined IRC (ricotz!~rico@p5B2AA972.dip0.t-ipconnect.de) | |
| 06:30 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 06:55 | alkisg has left IRC (alkisg!~Thunderbi@ubuntu/member/alkisg, Quit: alkisg) | |
| 06:59 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 07:22 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 07:25 | schlady has joined IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de) | |
| 07:26 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 268 seconds) | |
| 07:28 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 07:41 | maldridge1 has left IRC (maldridge1!~maldridge@cpe-76-183-148-124.tx.res.rr.com, Quit: WeeChat 1.3) | |
| 07:42 | maldridge has joined IRC (maldridge!~maldridge@69.13.217.92) | |
| 07:45 | tpe-cpp has joined IRC (tpe-cpp!c23fefeb@gateway/web/freenode/ip.194.63.239.235) | |
| 08:01 | maldridge has left IRC (maldridge!~maldridge@69.13.217.92, Ping timeout: 244 seconds) | |
| 08:13 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 09:01 | schlady has left IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de, Remote host closed the connection) | |
| 09:01 | schlady has joined IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de) | |
| 09:07 | schlady has joined IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de) | |
| 09:09 | schlady has left IRC (schlady!~schlady@ip1f111304.dynamic.kabel-deutschland.de, Remote host closed the connection) | |
| 09:25 | larryni has joined IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com) | |
| 09:42 | larryni has left IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com, Ping timeout: 256 seconds) | |
| 09:55 | larryni has joined IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com) | |
| 10:06 | khildin has joined IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be) | |
| 10:30 | schlady has joined IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de) | |
| 10:38 | schlady has left IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de, ) | |
| 10:41 | schlady has joined IRC (schlady!~schlady@141.53.32.60) | |
| 10:43 | schlady has left IRC (schlady!~schlady@141.53.32.60, Remote host closed the connection) | |
| 10:43 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 10:46 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Read error: Connection reset by peer) | |
| 10:47 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 10:53 | schlady has joined IRC (schlady!~schlady@141-53-32-60.ip.uni-greifswald.de) | |
| 10:57 | schlady has left IRC (schlady!~schlady@141-53-32-60.ip.uni-greifswald.de, Ping timeout: 240 seconds) | |
| 10:58 | gdi2k has joined IRC (gdi2k!~gdi2k@49.151.0.108) | |
| 10:59 | schlady has joined IRC (schlady!~schlady@141-53-32-60.ip.uni-greifswald.de) | |
| 11:16 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection) | |
| 11:22 | larryni has left IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com, Ping timeout: 240 seconds) | |
| 11:27 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 11:31 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 246 seconds) | |
| 11:32 | khildin has left IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be, Ping timeout: 256 seconds) | |
| 11:34 | larryni has joined IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com) | |
| 11:42 | os_a has joined IRC (os_a!c3707414@gateway/web/freenode/ip.195.112.116.20) | |
| 11:44 | <os_a> Hi!
| |
| 11:45 | gvy has joined IRC (gvy!~mike@altlinux/developer/mike) | |
| 11:47 | danau11 has joined IRC (danau11!~durban@66.251.57.114) | |
| 11:47 | larryni has left IRC (larryni!~larryni@host86-129-153-93.range86-129.btcentralplus.com, Quit: Leaving) | |
| 11:54 | schlady has left IRC (schlady!~schlady@141-53-32-60.ip.uni-greifswald.de, Ping timeout: 250 seconds) | |
| 11:58 | danau11 has left IRC (danau11!~durban@66.251.57.114) | |
| 12:27 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 12:32 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 260 seconds) | |
| 12:39 | <highvoltage> win 23
| |
| 12:39 | <alkisg> win some, lose some...
| |
| 12:48 | schlady has joined IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de) | |
| 12:56 | schlady has left IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de, Ping timeout: 265 seconds) | |
| 12:56 | schlady_ has joined IRC (schlady_!~schlady@141-53-221-236.ip.uni-greifswald.de) | |
| 13:19 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 13:19 | schlady_ has left IRC (schlady_!~schlady@141-53-221-236.ip.uni-greifswald.de, Remote host closed the connection) | |
| 13:25 | Phantomas has joined IRC (Phantomas!~ftsamis@ubuntu/member/phantomas) | |
| 13:57 | schlady has joined IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de) | |
| 13:59 | gbaman_ has joined IRC (gbaman_!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 14:03 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 240 seconds) | |
| 14:04 | gbaman_ has left IRC (gbaman_!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Ping timeout: 256 seconds) | |
| 14:05 | os_a has left IRC (os_a!c3707414@gateway/web/freenode/ip.195.112.116.20, Ping timeout: 246 seconds) | |
| 14:24 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 14:40 | gdi2k has left IRC (gdi2k!~gdi2k@49.151.0.108, Quit: Ex-Chat) | |
| 15:14 | gbaman has joined IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net) | |
| 15:37 | khildin has joined IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be) | |
| 16:05 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 16:13 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: $HOME) | |
| 16:19 | <muppis> $HOME not set; using /
| |
| 16:20 | <ogra_> your home is the whole world !
| |
| 16:21 | <muppis> :D
| |
| 16:31 | Grembler has left IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net, Quit: I Leave) | |
| 16:51 | Grembler has joined IRC (Grembler!~Ben@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net) | |
| 17:09 | schlady has left IRC (schlady!~schlady@141-53-221-236.ip.uni-greifswald.de, Remote host closed the connection) | |
| 17:13 | maldridge has joined IRC (maldridge!~maldridge@69.13.217.92) | |
| 17:25 | maldridge has left IRC (maldridge!~maldridge@69.13.217.92, Quit: kernel upgrade) | |
| 17:30 | maldridge has joined IRC (maldridge!~maldridge@69.13.217.92) | |
| 17:36 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 17:42 | <alkisg> vagrantc: what's your view on using a special ssh user, let's say the ltsp user, for clients to communicate with the server, to implement ltspd that way instead of using a SimpleHTTPServer?
| |
| 17:42 | It would have a special shell, it wouldn't allow password authentication etc etc
| |
| 17:44 | It could also be the other way around, the client could have sshd running and a special ltsp user and the server would connect to it
| |
| 17:53 | <vagrantc> alkisg: why ssh?
| |
| 17:53 | <alkisg> vagrantc: we're already using it anyway, and it's stable, offers encryption, socket forwarding, multiple connections etc
| |
| 17:54 | Any downsides?
| |
| 17:54 | <vagrantc> having to configure ssh server-side ... and running it client-side introduces lots of problems with hostkeys
| |
| 17:55 | <alkisg> Well, we'll either have `ltsp-config sshd` to configure /etc/ssh/sshd_config and put a special match stanza, or use /var/lib/ltsp/.ssh/authorized_keys, for server-side ssh,
| |
| 17:56 | or we can have the server's public key on the client's authorized keys for the opposite, which is easier
| |
| 17:56 | (the ltsp user's public key...)
| |
| 17:56 | <vagrantc> but the server would essentially have to ignore host keys when connecting to the client
| |
| 17:57 | <alkisg> how would any other ltspd service solve that issue?
| |
| 17:57 | Don't expect wonders :)
| |
| 17:58 | But any client offering a shell to execute commands on it... how much harm can that do?
| |
| 17:58 | It's just about configuration, which currently is sent unencrypted over the network
| |
| 17:59 | So it's 1000% more security than we have now, or than we could get with https or other technologies
| |
| 18:00 | secure boot is another issue, not solved at this point. When we are able to re-generate static random keys on the client, then we can tell the server to remember them and trust them only once
| |
| 18:01 | <vagrantc> ok, with an https server, we can configure a certificate server-side that's known to both the server and clients...
| |
| 18:02 | requiring modifications to the ssh server may be prohibited by some site policies (weather misguided or otherwise, they're real-world scenarios)
| |
| 18:02 | <alkisg> and if the clients know it, then another can't mimic the server?
| |
| 18:02 | I don't see why certificates are different from ssh keys
| |
| 18:03 | <vagrantc> i'm not talking about a shared secret key, but the traditional client-server model
| |
| 18:04 | technically, there really is no difference with ssh keys, yes... but ssh is well established for logging into systems, and many sites have policies regarding how you are able to configure login service
| |
| 18:05 | <alkisg> But we're using ssh anyway, and we don't need to modify sshd_config
| |
| 18:05 | We just need /var/lib/ltsp/.ssh/authorized_keys
| |
| 18:05 | * vagrantc wonders how that could be implemented without modifying sshd_config | |
| 18:05 | <alkisg> We can enforce things there, like the forced login command etc
| |
| 18:06 | http://serverfault.com/questions/142997/what-options-can-be-put-into-a-ssh-authorized-keys-file
| |
| 18:06 | Something like taht
| |
| 18:06 | *that
| |
| 18:06 | <vagrantc> how do you implement a customized authorized_keys file without modifying sshd_config to check that file?
| |
| 18:07 | <alkisg> It checks the user's authorized-keys anyway
| |
| 18:07 | <quinox> gitolite also has a completely locked down shell without any sshd modifications
| |
| 18:07 | khildin has left IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be, Ping timeout: 260 seconds) | |
| 18:07 | <alkisg> ltsp is a user, the clients would run ssh ltsp@server
| |
| 18:07 | and the ltsp user's $HOME is there
| |
| 18:07 | (in /var/lib/ltsp, like lightdm's home or other services)
| |
| 18:08 | <vagrantc> alkisg: ok.
| |
| 18:08 | * alkisg checks gitolite... | |
| 18:08 | * vagrantc wonders how many sites have an "ltsp" user | |
| 18:08 | <quinox> # head /home/git/.ssh/authorized_keys
| |
| 18:08 | # gitolite start
| |
| 18:08 | command="/usr/share/gitolite/gl-auth-command netrom",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB
| |
| 18:08 | (rest of key cut off)
| |
| 18:09 | * vagrantc often uses the "ltsp" user for throwaway test machines :) | |
| 18:09 | <vagrantc> yeah, i'm familiar with forced ssh commands
| |
| 18:10 | we'll then need one key for every command ... or the command we use needs to parse arguments
| |
| 18:10 | <alkisg> If in the future we're able to create random ssh-keys for the clients on boot, but have them use a seed like e.g. the output of `dmidecode` so that they're always the same, then we can easily implement the "trust phase" where the sysadmin needs to run something like `ssh-copy-id` for each client once
| |
| 18:10 | <vagrantc> the latter often being a security risk
| |
| 18:10 | <alkisg> stdin, not arguments
| |
| 18:10 | The connection would be permanent, for all the time the client is up
| |
| 18:10 | <vagrantc> arguments, stdin, whatever ... validated input
| |
| 18:10 | <alkisg> Yes, like we do now with ldminfod
| |
| 18:11 | And lts.conf parsing on the client (where we already have some issues with $vars :))
| |
| 18:11 | <vagrantc> no, ldminfod responds the same no matter what you tell it.
| |
| 18:11 | <alkisg> ah, what was it, ltsp-cluster then? ok...
| |
| 18:12 | * vagrantc doen't know ltsp-cluster well enough to speak about it | |
| 18:12 | <alkisg> ltspd will need argument handling in any case
| |
| 18:12 | That much is certain
| |
| 18:12 | It will need to know the client arch, ram, mac, cpu... to make decisions
| |
| 18:13 | all the web has argument handling, we can't block progress because it might not be implemented correctly...
| |
| 18:13 | <vagrantc> no, but we also should think about it.
| |
| 18:14 | <alkisg> Sure, and peer review the implementation etc
| |
| 18:14 | * vagrantc also wouldn't use the web as something worth emulating | |
| 18:14 | <alkisg> I'm just trying to balance the sshd vs https implementation now
| |
| 18:14 | <vagrantc> sure
| |
| 18:14 | <alkisg> (https == the other probable implementation for ltspd, which is also used in the web...)
| |
| 18:15 | <vagrantc> as long as we're not trusting arbitrary certificate authorities, that should be fine. :)
| |
| 18:15 | <alkisg> So which of those 2 would you vote for?
| |
| 18:15 | There's also socat+openssl like epoptes does now
| |
| 18:16 | But it seems too much ad-hoc to me
| |
| 18:16 | <vagrantc> so you're not happy with epoptes approach?
| |
| 18:16 | <alkisg> `socat unknown-server` blocks with 100% cpu in wily
| |
| 18:17 | Reported upstream, patch exists, but no bug tracker anywhere, communication is done with private emails
| |
| 18:17 | I prefer using more mainstream technologies whenever possible
| |
| 18:17 | sshd is very well tested
| |
| 18:17 | <vagrantc> so, the main advantage of ssh is that it's an already existing service that we've historically already depended on being present
| |
| 18:17 | <alkisg> https as well, although maybe not so much the python implementation that we'll use
| |
| 18:17 | We rely on it now as well, we can't stop using ssh, it's not only historical
| |
| 18:18 | And it supports a vast range of useful things, like even socket forwarding now
| |
| 18:18 | <vagrantc> well, technically i thin we could move away from ssh if we did fat clients only, for example
| |
| 18:18 | or some other remote X protocol
| |
| 18:18 | <alkisg> And use what for home, nfs?
| |
| 18:19 | <vagrantc> NFS, NFSv4, cifs ...
| |
| 18:19 | to me, if we're going to be gutting everything, we don't *have* to assume we'll need ssh.
| |
| 18:20 | <alkisg> I think that configuring those on the server correctly, with authentication, security etc, will be way more intrusive than having an ltsp ssh user with authorized_keys
| |
| 18:20 | Why would we Depend: https but not Depend: sshd?
| |
| 18:20 | <vagrantc> i don't really see not having ssh on *my* servers ...but i'm not 100% sure LTSP needs in in the future
| |
| 18:21 | it may very well be the best way forward, i'm just trying to keep an open mind
| |
| 18:22 | khildin has joined IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be) | |
| 18:22 | <vagrantc> so, the main disadvantage with an https implementation are ... still have to negotiate keys/certs somehow, and more code left to implement?
| |
| 18:22 | <alkisg> If we document the phases of communication, then if someone wants, he can implement that "backend" differently, e.g. with https...
| |
| 18:23 | The ssh connection will always be up and can be two-ways
| |
| 18:23 | The client can request things from the server, or the server can instruct the client to shutdown etc
| |
| 18:24 | The https connection will be stateless and that's more stable, but that can only do a few things
| |
| 18:24 | It can't forward sockets or ports or file systems
| |
| 18:25 | <vagrantc> well, the restricted login shouldn't be able to do those things either...
| |
| 18:26 | <alkisg> Why wouldn't it forward sockets?
| |
| 18:26 | E.g. suppose that you have sshd running on the client, and listening only on localhost, so that noone can login there from the local network,
| |
| 18:26 | and the client doing a port forward of the local 22 port to the server, so that only the server's ltsp user can login to the client
| |
| 18:27 | Voila, you now have a channel to run commands on the client without authentication, secure, which allows multiplexing etc
| |
| 18:28 | <vagrantc> the security relies on whatever shell/forced-command we've set up that user to use
| |
| 18:29 | <alkisg> If we only want port+socket forwarding, it can be /usr/sbin/nologin
| |
| 18:29 | If we want parameter parsing, it will need to be /usr/share/ltsp/login-script
| |
| 18:30 | On the client side, the ltsp user can have /bin/sh as the shell, np there, as it will only allow the server to login there
| |
| 18:31 | <vagrantc> so as soon as a client boots, the server connects to it?
| |
| 18:31 | <alkisg> At init-ltsp.d
| |
| 18:31 | <vagrantc> and leaves a running ssh sesision?
| |
| 18:31 | khildin has left IRC (khildin!~khildin@ip-213-49-86-226.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 18:31 | <alkisg> Instead of 05-getltsconf or so
| |
| 18:31 | Yes
| |
| 18:32 | <vagrantc> how does the client tell the server to connect?
| |
| 18:32 | <alkisg> With a local port forward of 22 if we want the server to be able to run things on the client
| |
| 18:32 | Are you asking about the boot/configuration phases?
| |
| 18:32 | how? or when?
| |
| 18:32 | <vagrantc> yes.
| |
| 18:33 | i.e. client boots ... how does the server know where to connect?
| |
| 18:33 | or when
| |
| 18:33 | <alkisg> At init-ltsp.d, we'll replace 05-getltscfg with 05-connect-to-server-with-ssh
| |
| 18:34 | <vagrantc> ok, so there are two ssh connections, one from the client to the server, and another from the server to the client?
| |
| 18:34 | <alkisg> and at that point we'll tell the server the client ram, cpu etc, and get the configuration we need
| |
| 18:34 | that one connection will forward port 22 from the client to the server
| |
| 18:34 | The server doesn't need to connect at all, it won't use it
| |
| 18:34 | The sysadmin will use that via a tool when he wants, asyncrhonously
| |
| 18:34 | i.e. ltsp-exec pcxx command
| |
| 18:35 | <vagrantc> and that will connect back to the server via ssh to the client?
| |
| 18:35 | <alkisg> That `sudo ltsp-exec` tool will check the available sockets, locate pcxx, and login via ssh and run the command
| |
| 18:36 | E.g. if we want to say it with ports, if pc01 forwarded port 22 of the client to the server's 1234, then ltsp-exec would connect to 1234
| |
| 18:36 | But we would prefer sockets there, not ports, for security and clarity of filenames
| |
| 18:36 | <vagrantc> yes, spinning up lots of arbitrary ports on the server seems dangerous
| |
| 18:37 | <alkisg> ltsp-exec would of course use private ssh keys, and the public keys would be in the client image authorized-keys
| |
| 18:37 | <vagrantc> hah.
| |
| 18:38 | <alkisg> So, encryption over encryption :D
| |
| 18:38 | <vagrantc> client-side, it could generate random keys, push the public host and authentication keys to the server, and then each client could have an independent set of keys...
| |
| 18:38 | it wouldn't need deterministic keys
| |
| 18:38 | <alkisg> If the server is willing to automatically trust them, sure
| |
| 18:39 | <vagrantc> well, it wouldn't have to trust them globally
| |
| 18:39 | <alkisg> We can't avoid that until we can find a way to seed ssh-keygen
| |
| 18:39 | <vagrantc> the server-side ssh commands can specify the known_hosts file it uses
| |
| 18:41 | the client image has a trust path to the server (the built-in /etc/ssh/ssh_known_hosts shipped in the booted image) ... and a way to login to the server as a specified user ... which can then push it's generated keys to the server at boot... which then uses those keys to verify it's connecting to the same host, and uses a custom login key
| |
| 18:42 | <alkisg> Yes, after init-ltsp.d/05-ssh runs, the channel is secured
| |
| 18:42 | <vagrantc> basically, that avoids the need for a shared private key or deterministic keys on the client
| |
| 18:42 | <alkisg> Any client can get the server's ssh_known_hosts and claim that it's an ltsp client
| |
| 18:42 | <vagrantc> this does feel a bit like a maze, though.
| |
| 18:43 | <alkisg> So before 05-ssh, there's no complete security...
| |
| 18:43 | <vagrantc> alkisg: sure, but there is information available in the ssh connection that the server can validate
| |
| 18:43 | such as the ip address
| |
| 18:43 | <alkisg> Which can be spoofed etc etc
| |
| 18:43 | It's the best we can do at this point
| |
| 18:44 | And waaaaay better than what we have now, security-wise
| |
| 18:44 | <vagrantc> it's much easier to spoof something with a deterministic private key than one that's generated every boot.
| |
| 18:44 | <alkisg> You have a "join domain" step there
| |
| 18:45 | <vagrantc> it burns!
| |
| 18:45 | <alkisg> Where the sysadmin is called to manually accept the key
| |
| 18:45 | :D
| |
| 18:45 | Imagine the client booting, and stopping at 05-ssh, and displaying an ncurses UI, saying "Please enter a domain administrator password to have this machine join the ltsp realm" :P :D
| |
| 18:45 | <vagrantc> the concept of a "secure" deterministic key is highly questionable.
| |
| 18:47 | <alkisg> About https, it will be more straight forward, but it won't be able to do things like `ltsp-exec`
| |
| 18:47 | <vagrantc> one of the things i've always loved about LTSP is being able to plug in an arbitrary machine and boot it and it just works ... requiring a "domain join" equivalent would be very unfortunate.
| |
| 18:48 | <alkisg> Well you either need to store something on the client (boot from a usb stick or internal DOM with some keys), or reuse some state that the client has that is private and unique (like arguably the output of dmidecode)
| |
| 18:48 | So.... sshd or https? :)
| |
| 18:48 | <vagrantc> alkisg: could do the same key-exchange over https and then the server could tell it to start up an sshd on $PORT and allow key $KEY to run $COMMAND
| |
| 18:49 | <alkisg> ssh again
| |
| 18:49 | <vagrantc> both.
| |
| 18:49 | <alkisg> We can do the socket forwarding in the opposite side
| |
| 18:49 | If sshd runs on the client, the persistent connection can be from the server to the client
| |
| 18:50 | <vagrantc> alkisg: you've explained it numerous times, and i still get lost in the explanation
| |
| 18:50 | <alkisg> The client boots and reaches 05-ssh
| |
| 18:50 | <vagrantc> alkisg: which suggests to me it's kind of complicated to explain, let alone document, and for a sysadmin to grasp
| |
| 18:50 | <alkisg> Hehe
| |
| 18:50 | <vagrantc> so i worry about that a bit
| |
| 18:50 | <alkisg> It's brainstorming, not documentation
| |
| 18:50 | <vagrantc> sure
| |
| 18:51 | <alkisg> And not many people bother with socat + openssl in epoptes, it just works
| |
| 18:51 | <vagrantc> i still don't see why the client needs something deterministic ... it can tell the server "hi, i'm client FOO, please use these keys to connect"
| |
| 18:51 | <alkisg> sysadmins need to know about ltsp-exec, not what's behind the scenes
| |
| 18:51 | <vagrantc> until something doesn't work
| |
| 18:51 | <alkisg> That (determenistic) part is theoretical, let's leave it for another time
| |
| 18:52 | Then they file bug reports... I think ldm's plugin mechanism is much more difficult to comprehent than ssh socket forwarding
| |
| 18:52 | <vagrantc> key negotiation is hard, let's go shopping!
| |
| 18:52 | <alkisg> hehe
| |
| 18:55 | <vagrantc> so, let's even leave ltsp-exec out of the picture, and get a solid explanation of the phases you see
| |
| 18:55 | and come back to that once that's clearer
| |
| 18:56 | <alkisg> All of them? Many are unrelated to the technology we'll select. But ok let's go
| |
| 18:57 | I haven't yet made up my mind about the initramfs. If we can stick to the dhcp info, let's use that one only without contacting the server, it will keep the requirements to a minimum (like wget for https)
| |
| 18:57 | We only need the mount parameters there, hopefully dhcp is enough for all use cases there
| |
| 18:57 | So the first phase is init-ltsp.d, at 05-ssh
| |
| 18:58 | There the client sends some info, mac, ip, cpu, ram, graphics card etc, and asks for the equivalent of lts.conf
| |
| 18:59 | That config can contain commands for the client to run at the next phase, which is at ltsp-client-core.init, when services get to run. But I don't think that the client needs to contact the server again at that point.
| |
| 19:00 | The next point that the client will run commands is at the DM, like the ldm-script I*, X*, K* points now
| |
| 19:00 | Before login it will need to contact the server again, and after logout
| |
| 19:01 | We leave the asynchronous ltsp-exec (or ltsp-exec-a-cron-job) bits out of the picture for now...
| |
| 19:01 | It's very similar to what ltsp-cluster has now in the code already
| |
| 19:01 | It just need to be called in some generic way, fetch-config <params>, not -cluster...
| |
| 19:02 | <vagrantc> currently, the configuration is only received once, but i remember ltsp-cluster allowing it to change every time it runs
| |
| 19:03 | <alkisg> Right
| |
| 19:03 | Furthermore, it should be able to send more things, like even .xsession files
| |
| 19:03 | Not just key=value lines
| |
| 19:04 | <vagrantc> ok, so that all seems clear enough at that level view... :)
| |
| 19:05 | * vagrantc wonders if ltsp-client-core.init could just disappear, and be handled by configuring everything in init-ltsp.d | |
| 19:06 | <alkisg> We do need a `now it's time to run services` hook...
| |
| 19:07 | <vagrantc> what services that wouldn't be handled by the usual init system?
| |
| 19:07 | <alkisg> We can either install that hook at init-ltsp.d or from debian/package.systemd, np there
| |
| 19:08 | E.g. SCREEN_07=lightdm SCREEN_08=lightdm, we don't want that?
| |
| 19:10 | <vagrantc> that's a valid question, but even if the answer is yes, we could possibly generate .service files (or other init scripts) in init-ltsp.d instead
| |
| 19:10 | <alkisg> Yup, that's what I said, either install the hook (service file) from init-ltsp, or ship it
| |
| 19:11 | * vagrantc can smell the torches and pitchforks coming out of the woodwork | |
| 19:11 | <alkisg> :)
| |
| 19:12 | <vagrantc> ok, so ... what does the 05-ssh thing look like?
| |
| 19:12 | <alkisg> That, or the new getltscfg tool?
| |
| 19:13 | 05-ssh is similar to the current /usr/sbin/epoptes-client
| |
| 19:13 | It gathers some data from the client and send them to the server
| |
| 19:13 | and then gets a "personalized" configuration for the client, and stores it in /var/cache/ltsp...
| |
| 19:13 | <vagrantc> ok, and it gets back the equivalent of lts.conf, with some extra possibilities?
| |
| 19:13 | <alkisg> Right
| |
| 19:14 | <vagrantc> that seems fairly uncontroversial
| |
| 19:14 | <alkisg> If you want to go far enough, you can have the server ship all the ltsp-client code dynamically
| |
| 19:14 | It isn't large
| |
| 19:15 | We're doing something similar with epoptes, allowing the server to send code to the client
| |
| 19:15 | The result is that epoptes-client doesn't need to be updated frequently
| |
| 19:15 | <vagrantc> one of the frustrating things with the image-based approaches is having to rebuild the image for a one-line change in a file, or adding a single file, etc.
| |
| 19:15 | so that sounds appealing
| |
| 19:16 | <alkisg> You could e.g. have live CDs or local squashfs images, years old, and have them working with the latest ltsp because they fetch it dynamically from the server
| |
| 19:16 | <vagrantc> but in the worst-case, it would basically replace lts.conf ... ok.
| |
| 19:20 | alkisg: so when you explain it like that, i feel like it get it ... i think i get lost when you start talking about local to remote and back-again port forwarding and sockets and such
| |
| 19:21 | <alkisg> I think I get too excited with all the possibilities that I forget to focus on the base first :)
| |
| 19:21 | I'm still not sure where to go with the implementation though... sshd+shell or https+python...
| |
| 19:24 | vagrantc: are you ok with sshd running on the client, with only the server being able to connect and execute commands there by default?
| |
| 19:24 | And even scp files?
| |
| 19:25 | If yes, then we can use that for the bulk of the implementation, not only for ltsp-exec
| |
| 19:25 | I.e. the client would say in 05-ssh:
| |
| 19:26 | server, my mac is xxx, ip=yyy etc, give me my configuration
| |
| 19:26 | ...at that point the server would ssh, patch things on the client, copy files, whatever, and then just reply with "you are ready, continue" :D
| |
| 19:26 | So the implementation there is shell, server-side
| |
| 19:26 | And we have selected the technology we want and we can start coding
| |
| 19:29 | <vagrantc> that sounds a lot like ansible :)
| |
| 19:32 | * alkisg verified that sshd can run at init-ltsp.d, it doesn't seem to have any other services as a dependency... | |
| 19:33 | * vagrantc really doesn't like running services from init-ltsp.d | |
| 19:33 | <alkisg> Heh, a workaround for people trying to run sshd on the clients... RCFILE_01="dpkg-reconfigure openssh-server" - should be enough...
| |
| 19:33 | That's a good point though, we don't have any guarantee that launching sshd from init-ltsp.d will keep working
| |
| 19:34 | <vagrantc> we could actually create a second sshd configuration for the client configuration
| |
| 19:34 | <alkisg> So sshd is good enough for ltsp-exec, but not while the client is still booting
| |
| 19:35 | Ah, sure, another port, configuration file etc
| |
| 19:35 | <vagrantc> then if the user manually configures sshd, we won't step on those toes
| |
| 19:36 | <alkisg> http://www.commandlinefu.com/commands/view/13289/reverse-sshfs-mount
| |
| 19:36 | This is not a service... it can run temporarily from init-ltsp.d and offer access to the whole client file system to the server
| |
| 19:37 | Very powerful, but it does sound complicated
| |
| 19:38 | <vagrantc> complicated, and error-prone
| |
| 19:38 | it doesn't really suceed on the "least access necessary to accomplish the task"
| |
| 19:38 | test
| |
| 19:38 | could sshfs mount some scripts for the client to run...
| |
| 19:39 | <alkisg> unauthenticated sshfs access to the server? even read-only?
| |
| 19:39 | <vagrantc> sshfs server:/some/dir/clientXXX/setup.d/
| |
| 19:40 | run-parts setup.d
| |
| 19:40 | something like that
| |
| 19:41 | <alkisg> The ltsp user could login chrooted in that setup.d dir, but wouldn't you consider that a security issue?
| |
| 19:41 | <vagrantc> all of the dynamic configuration is a bit of a security issue
| |
| 19:42 | basically, we're giving the server root access to dynamically configure the client ... which it always has had through lts.conf, the image itself, etc.
| |
| 19:42 | <alkisg> In the sshfs command above, isn't it the client that connects to the server via sshfs?
| |
| 19:42 | I.e. aren't we giving sftp access to the ltsp user?
| |
| 19:43 | <vagrantc> but there's a simplicity in the image itself being shipped out ... "what's in the image is what we're running" ... dynamic configuration does make it considerably more complicated
| |
| 19:43 | alkisg: it could be a read-only sftp connection to a restricted directory ... but yes.
| |
| 19:43 | alternately, it could just shunt a tarball over the ssh pipe, and we unpack it and run it
| |
| 19:44 | <alkisg> Well, with those tools, we could boot as an "ltsp client" any live cd, they all have ssh installed - it would only need a custom init command
| |
| 19:44 | <vagrantc> right
| |
| 19:45 | <alkisg> No more need for an ltsp-client package, just a small /sbin/init-ltsp command that runs `ssh to the server; and give control to the server`
| |
| 19:47 | <vagrantc> something feels unsatisfying about that.
| |
| 19:48 | <alkisg> We have a "do you trust this server" step there ... :)
| |
| 19:49 | <vagrantc> so, the server-client interaction then relies on the server being able to reliably know all the correct configuration for the client
| |
| 19:50 | so the server-side needs to be multi-distro and multi-release aware ...
| |
| 19:50 | <alkisg> Evolution... from ltsp-build-client patching chroots, to init-ltsp.d patching live systems, to init-ltsp-ssh handing complete control to the server :D
| |
| 19:51 | <vagrantc> so, i see advantages, but it does seem rather complicated
| |
| 19:52 | * vagrantc still hasn't uploaded ltsp 5.5.5 | |
| 19:52 | <alkisg> ...do we have an answer on the sshd | https? Or do we postpone it for another time?
| |
| 19:53 | Lots of information today though, maybe it does need some time to settle
| |
| 19:56 | Maybe the simpler thing to do is (1) https for config, (2) code on the client, not on the server, (3) leave ssh + ltsp-exec up to epoptes, i.e. epoptes-exec..
| |
| 19:58 | <vagrantc> certainly a simpler proposal
| |
| 20:00 | <alkisg> and a *lot* less flexible :)
| |
| 20:00 | <vagrantc> yes
| |
| 20:00 | <alkisg> Imagine a student coming in the ubuntu-based ltsp classroom with a fedora laptop
| |
| 20:01 | ...and booting with init=init-ltsp, over wifi, in a completely customized (cow, temp) systemd, suitable for the classroom, while utilizing all the local disk speed :D
| |
| 20:01 | *system, not systemd.. meh I typed it a lot recently
| |
| 20:01 | <maldridge> if I was a student, I don't think I'd boot my laptop over the network like that; too many things could go wrong
| |
| 20:01 | <alkisg> cow, nothing written locally
| |
| 20:02 | If you had bank accounts there sure, it wouldn't be appropriate
| |
| 20:02 | <vagrantc> "trust us"
| |
| 20:02 | supporting arbitrary distros on the server-side seems... optimistic
| |
| 20:03 | <maldridge> the "trust us" approach doesn't sound quite right
| |
| 20:03 | <alkisg> Theoretically it would just be a folder that I could download from fedora themselves
| |
| 20:03 | OK anyway enough dreaming... it seems to me https is more likely to be widely accepted
| |
| 20:04 | It will be a little tricky to send multiple files etc on one request, but it should be doable
| |
| 20:04 | <vagrantc> send an archive back
| |
| 20:05 | with a standardized format
| |
| 20:05 | * alkisg is thinking about multiple calls, "call me again I have more data for you" | |
| 20:05 | <vagrantc> always send all the data?
| |
| 20:05 | latest revision wins
| |
| 20:06 | if we're not configuring *everything* it shouldn't be much data overall
| |
| 20:06 | <alkisg> Let's say the client asks the server about the ldminfod information
| |
| 20:06 | So it should reply with a few .xsession files, some locale info etc
| |
| 20:06 | Not all of the information is files, we can't easily use tar
| |
| 20:07 | We could use a shell-based output... cat >file.1 <<EOF etc
| |
| 20:07 | I.e. everything that the server sends is just executed client-side
| |
| 20:07 | It wouldn't be binary-safe, but I don't think we need that
| |
| 20:08 | https does need encoding though, the server side would definately be python
| |
| 20:08 | (or php if we wanted a conventional web server)
| |
| 20:08 | <vagrantc> alkisg: if you do start to code this, please use python3
| |
| 20:09 | <alkisg> ssh would be much more simple there, jsut scp + commands
| |
| 20:09 | <vagrantc> no php!
| |
| 20:10 | <alkisg> ltsp-cluster used php, didn't it? :P :D
| |
| 20:10 | (that's why it never got in debian.... :D)
| |
| 20:10 | <vagrantc> and how's ltsp-cluster doing these days? :P
| |
| 20:11 | * vagrantc thought php had finally gone legacy | |
| 20:11 | <alkisg> Don't let Hyperbyte hear you
| |
| 20:11 | He'll crash ltsp.org
| |
| 20:13 | Hmm it's getting rather late here... /me needs to go... bb guys! :)
| |
| 20:13 | <vagrantc> alkisg: well, thanks for talking all that out!
| |
| 20:13 | * vagrantc waves to alkisg | |
| 20:13 | <alkisg> Thank you too, we'll see how this goes
| |
| 20:13 | alkisg is now known as work_alkisg | |
| 20:15 | * vagrantc is amazed at how much work alkisg gets done while sleeping | |
| 20:38 | <Hyperbyte> Heh... sure guys, go ahead and bash php... meanwhile, it's still running half the web. :-)
| |
| 20:52 | <vagrantc> Hyperbyte: so we should migrate LTSP to a PHP webapp?
| |
| 20:52 | :)
| |
| 20:52 | * vagrantc thought webapps were all javascripty nowadays | |
| 20:57 | <Hyperbyte> Javascript is client side protocol. It's useless without a server side backend.
| |
| 21:16 | gbaman has left IRC (gbaman!~gbaman@cpc15-belf9-2-0-cust171.2-1.cable.virginm.net, Remote host closed the connection) | |
| 21:32 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 21:34 | gbaman has joined IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk) | |
| 21:43 | gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Remote host closed the connection) | |
| 21:52 | gbaman has joined IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk) | |
| 21:55 | * Phantomas saw the conversation above and started working again on the ltsp config parser he was writing, which supports ".d/" style configuration (ltsp.d/10-test.conf, 20-bar.conf, 25-foo.conf etc) with DEFAULT section support and multiple inheritance (like 'LIKE') support | |
| 22:32 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 22:42 | gbaman has left IRC (gbaman!~gbaman@members.unit1.farsetlabs.org.uk, Remote host closed the connection) | |
| 23:02 | tex-rt has joined IRC (tex-rt!4ac0a1b7@gateway/web/freenode/ip.74.192.161.183) | |
| 23:05 | <tex-rt> New Ubuntu 14.04 with Shuttle acting as thin clients - display detection identifying 'default display' and an actual physical display - it acts like a dual display. We'd like to have it default to a single physical display for users.
| |