IRC chat logs for #ltsp on irc.libera.chat (webchat)

Request log from specific day:

Channel log from 18 February 2019 (all times are UTC)

01:08	vagrantc_ has joined IRC (vagrantc_!~vagrant@unaffiliated/vagrantc)
01:54	vagrantc_ has left IRC (vagrantc_!~vagrant@unaffiliated/vagrantc, Quit: leaving)
02:52	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
03:25	lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-166.isotelco.net.br)
04:52	<alkisg> Got it, http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes
04:52	So libnss-external is needed; python isn't enough
04:53	Whoops too early in the morning. That's just libnss-extrausers, which is fine
04:59	So afaik ltsp6 won't need an ltsp-client package at all; just just prerequisites, notably nbd-client and pam-python :)
05:57	Da-Geek has joined IRC (Da-Geek!~Da-Geek@178.153.171.111)
06:16	statler has joined IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de)
06:16	Da-Geek_ has joined IRC (Da-Geek_!~Da-Geek@37-186-42-131.ip.as39912.net)
06:19	Da-Geek has left IRC (Da-Geek!~Da-Geek@178.153.171.111, Ping timeout: 255 seconds)
06:41	kjackal has left IRC (kjackal!~quassel@2a02:587:3105:5d00:c192:76d8:48ce:4723, Ping timeout: 258 seconds)
06:49	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:22	kjackal has joined IRC (kjackal!~quassel@2a02:587:3105:5d00:91a9:d04a:8358:403e)
09:09	<alkisg> !ltsp-pam
09:09	<ltsp> I do not know about 'ltsp-pam', but I do know about these similar topics: 'ltsp-pnp'
09:10	<alkisg> !learn ltsp-pam as The new focus for LTSP client authentication: documentation: http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes, code: https://git.launchpad.net/~ltsp-upstream/ltsp/+git/ltsp-pam
09:10	<ltsp> The operation succeeded.
09:17	kjackal has left IRC (kjackal!~quassel@2a02:587:3105:5d00:91a9:d04a:8358:403e, Ping timeout: 258 seconds)
09:18	kjackal has joined IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr)
09:19	nehemiah has joined IRC (nehemiah!~nehemiah@hs-user-138.wia.cz)
09:30	statler has left IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de, Remote host closed the connection)
10:05	statler has joined IRC (statler!~Georg@gwrz3.lohn24.de)
10:07	Da-Geek_ has left IRC (Da-Geek_!~Da-Geek@37-186-42-131.ip.as39912.net, Read error: Connection reset by peer)
10:08	Da-Geek_ has joined IRC (Da-Geek_!~Da-Geek@37-186-42-131.ip.as39912.net)
10:39	nehemiah has left IRC (nehemiah!~nehemiah@hs-user-138.wia.cz, Read error: Connection reset by peer)
11:58	Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
13:54	Da-Geek_ has left IRC (Da-Geek_!~Da-Geek@37-186-42-131.ip.as39912.net, Remote host closed the connection)
15:46	adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.48.253)
15:49	adrianorg has left IRC (adrianorg!~adrianorg@191.32.101.9, Ping timeout: 250 seconds)
16:18	kjackal_v2 has joined IRC (kjackal_v2!~quassel@2a02:587:3105:5d00:91a9:d04a:8358:403e)
16:18	kjackal has left IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr, Ping timeout: 240 seconds)
16:24	kjackal_v2 has left IRC (kjackal_v2!~quassel@2a02:587:3105:5d00:91a9:d04a:8358:403e, Ping timeout: 258 seconds)
16:25	kjackal has joined IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr)
16:52	kjackal has left IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr, Ping timeout: 255 seconds)
16:52	adrianor1 has left IRC (adrianor1!~adrianorg@177.18.48.253, Ping timeout: 268 seconds)
17:12	kjackal has joined IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr)
17:25	adrianorg has joined IRC (adrianorg!~adrianorg@177.18.48.253)
17:39	kjackal has left IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr, Ping timeout: 246 seconds)
17:40	sutula has left IRC (sutula!~sutula@207-118-151-61.dyn.centurytel.net, Quit: 'sutula has left the building')
17:44	sutula has joined IRC (sutula!~sutula@207-118-151-61.dyn.centurytel.net)
17:50	kjackal has joined IRC (kjackal!~quassel@2a02:587:3105:5d00:91a9:d04a:8358:403e)
19:42	vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 250 seconds)
19:43	vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
19:44	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
19:44	<alkisg> !ltsp-pam
19:44	<ltsp> ltsp-pam: The new focus for LTSP client authentication: documentation: http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes, code: https://git.launchpad.net/~ltsp-upstream/ltsp/+git/ltsp-pam
19:45	* alkisg tried those and got some entries in the server's auth.log while trying to login on the client... but, it eventually failed :/
19:46	<vagrantc> been a while since i tried them ... maybe december 2016 :)
19:47	<alkisg> vagrantc: do you think this architecture will support things like LDM_AUTOLOGIN and keyring unlocking and smart cards etc?
19:47	E.g. local autologin doesn't need a password, can we manupilate the pam stack to insert a password from lts.conf in that point?
19:48	Or, how are smart cards going to be translated to ... what, passwordless ssh?
19:48	I wonder if it would be best to just rewrite ldm in python and call it a day :D
19:49	That could handle password expiry and everything; except I'm not sure how well it will fit with systemd session handling and wayland launching etc, that part might be harder :/
19:50	Or maybe we could just securely transfer /etc/shadow to the client :P
19:52	adrianorg has left IRC (adrianorg!~adrianorg@177.18.48.253, Ping timeout: 250 seconds)
19:56	<vagrantc> LDM_PASSWORD_HASH essentially transfers individual entries from /etc/shadow
19:56	not really, but sort of
19:57	alkisg: i think i tested it with ssh keys before
19:57	alkisg: so in that sense, it's possible
19:57	i'm not sure about all the other things
20:12	<alkisg> vagrantc: well, it stores the hash locally after it succeeds, and it's just one entry
20:12	Would an implementation that copied e.g. all of /shadow over ssh, be acceptable for e.g. debian?
20:13	vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 255 seconds)
20:14	<alkisg> E.g. we can have the clients get shadow over https just before login; but while for schools here that wouldn't be a big deal, I think some may complain...?
20:14	(of we could tell them to use ldap/kerberos/nfsv4 in that case, and call it a day :D)
20:15	vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
20:16	<mwalters> as long as there's some sort of client auth for the https request
20:17	<alkisg> There can be a secret key transferred to the client at boot; but not user input; because then we might as well use pam
20:17	<mwalters> yah
20:17	that's fine with me
20:18	ideally something random?
20:18	<alkisg> That would be a really easy implementation :D
20:18	<mwalters> or psuedorandom, that isn't the same for each client/boot
20:18	<alkisg> No, even better: something that is generated by the client hardware
20:18	So that the client knows it, and noone else, not even the server
20:18	<mwalters> mac for entropy?
20:18	<alkisg> like dmidecode \| md5sum
20:18	<mwalters> that's probably "good enough" yeah
20:19	<alkisg> So when the client boots and asks for the initramfs, it sends that key, and the server will only answer to that client on the next requests if it sends that key again
20:20	<mwalters> I haven't looked into it... but I'm guessing you could do some sort of mac whitelisting for the pxebooting?
20:20	(with dnsmasq)
20:20	<alkisg> macs and ips can be spoofed easily
20:20	dmidecode requires root access to the client hardware
20:20	<mwalters> sure, I'm just thinking of extra annoyances
20:20	<alkisg> The problem with trusted network booting is that you need to trust the client once, for the initial secret exchange,
20:20	<mwalters> to keep unauthorized clients out
20:21	yah
20:21	<alkisg> well, unless the client has a bit of local storage
20:21	So, after all the clients boot, we can "lock" the server and tell it "you'll only hand out shadow to those clients"
20:22	<mwalters> well lets see what the concern is here fully... someone pretends to go through the initrd process... gets a copy of the shadow file
20:23	<alkisg> And can brute force it
20:23	<mwalters> yup
20:23	<alkisg> So something like this: "ltsp-start-learning-clients => allows new clients to netboot, ltsp-stop-learning-clients => only allows known clients",
20:24	<mwalters> I have a lot of "transient" clients
20:24	our employees are in and out a bunch =/
20:24	<alkisg> would force the "hacker" to use a live cd and get root on a client and run the ltsp code, in order to get the secret key, and then start to fake things
20:24	<mwalters> (not that they shutdown their clients even though I've asked them to ;) )
20:24	<alkisg> You could use ldap :D
20:24	lucascastro has left IRC (lucascastro!~lucascast@177-185-139-166.isotelco.net.br, Remote host closed the connection)
20:24	<mwalters> I just worked so hard to avoid ldap D:
20:24	<alkisg> Haha
20:25	What are you using, the simple ltsp model with one server with the users, and the ldm/ssh access?
20:25	<mwalters> freeipa feels so janky
20:25	yah
20:25	the "out of the box" stuff
20:25	adrianorg has joined IRC (adrianorg!~adrianorg@177.18.48.253)
20:25	<mwalters> we don't have many user changes on the linux boxes, so right now I'm just managing manually
20:25	(only 4 servers)
20:26	but yeah, only really need to add users when we get new full-time employees... and remove them on terminations
20:26	plan was to write some bash scripts in the next month or two to add user to all servers/remove... keep UID/GID in sync
20:27	<alkisg> Is ldap really so annoying that you'd use passwd syncing over it?
20:27	I haven't used it yet...
20:28	<mwalters> my last "real" experience was setting up ad/samba/ldap auth on linux box over in israel... had so many weird issues with it
20:28	this was probably back in like... 2010
20:28	<alkisg> Maybe that's too much, and plain ldap is simpler
20:28	<mwalters> I haven't used FreeIPA, but I don't have AD here either
20:29	I did a quick test box of freeipa... had strange issues where the http resources didn't get installed right
20:29	a lot of it is really I don't want "yet ANOTHER service" to worry about :D
20:30	<alkisg> Not freeipa, slapd: https://help.ubuntu.com/lts/serverguide/openldap-server.html.en
20:31	<\|\|cw> free IPA and AD are quite a lot more than just ldap
20:31	<mwalters> so you're just not going to hook pam with the login manager?
20:31	and make a direct ldap request?
20:33	sure, but we're still probably talking 4 ldap servers for my 4 ltsp boxes separated by wan =/
20:33	...and then replication =/
20:33	<alkisg> You need 1 server and 3 caching replicas
20:33	<mwalters> yeah
20:33	<alkisg> Those things are managed by ldap though
20:33	Not by rsync-based user scripts
20:33	<mwalters> "What was wrong with bash scripts?"(tm)
20:36	<vagrantc> alkisg: copying all of /etc/shadow seems like a problematic security behavior by default, definitely.
20:36	<alkisg> Eh, the default would be "please setup ldap; if you don't, then this is the lame fallback :D"
20:37	Although ldap isn't enough as it doesn't get us an ssh socket, so we'd need kerberos and nfsv4 too...
20:37	OK ok yeah pam would be saner
20:37	<mwalters> :D
20:37	<alkisg> Let's hope it works out
20:38	<mwalters> pam also gets you... anything with a pam module :D
20:38	<vagrantc> alkisg: what is it you're trying to solve?
20:38	<alkisg> vagrantc: well, ltsp-pam not working
20:38	Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
20:38	<alkisg> Also, I'm not sure if pam-python is maintained,
20:38	<vagrantc> maybe something broke in the last two years, but it worked last i tested it
20:38	<alkisg> and, I don't know if paramiko has a lot of performance overhead,
20:39	and I'm not sure if it will actually work for ldm_autologin etc
20:39	<vagrantc> yeah, pam-python looks a little hopeless ... if it's still not upgraded to python3, with python2 being unmaintained as of 2020 ... urg.
20:39	<alkisg> If I understood it correctly, all the /home traffic will get through paramiko, which means python and not c?
20:39	<vagrantc> that was still just sshfs
20:40	<alkisg> sshfs over the paramiko socket?
20:40	Or with second authentication without a library involved?
20:41	The pam-python maintainer is a debian guy, he said he'd have it ready for buster... yet now it's freezed, isn't it? And pam-python is still py2
20:43	vagrantc: I think the libpam-sshauth approach didn't have all those limitations, what was the security issue with that?
20:43	I read something about a security issue in irclogs, but there weren't any details
20:43	statler has left IRC (statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection)
20:47	<vagrantc> alkisg: oh, there was a severe security issue with libpam-sshauth, but it was fixed
20:47	<alkisg> Ah, so it's still a viable option?
20:47	<vagrantc> alkisg: basically gave root permissions at login prompt
20:47	<alkisg> OK I thought it was a design issue
20:48	<vagrantc> there may be other similar goblins
20:49	<alkisg> vagrantc: is getting passwd and group (not passwd) over https acceptable? With some minor protection like a secret key when the client boots?
20:49	In some cases this might make things easier, having the user accounts ready before the DM loads and displays a list
20:49	<vagrantc> that's mostly okish- we've been doing that with localapps/fatclients over ssh
20:49	but /etc/shadow is another matter ... there we were more selective
20:49	<alkisg> Yes but only after user authentication
20:50	Sure, understandable
20:50	Thanks for all the input.. Oh, long road ahead. UEFI booting solved, pam will take longer!
20:50	<vagrantc> alkisg: i'm pretty sure the libpam-python hooks just created a master ssh socket over which you could do normal ssh operations
20:51	so not shunting everything over paramiko or whatever ... that was just to establish the master socket
20:51	<alkisg> Ehm... if we're not calling `ssh`, I'm not sure how's that possible
20:51	<vagrantc> maybe we'd have to do the libpam-python port to python3 ourselves :/
20:52	it's been a while since i looked at it, but that's my memory
20:52	<alkisg> I mean, if we create a socket with paramiko, it's always handled by paramiko, even if we use sshfs -S socket aftewards
20:53	But ok I can just switch to talking directly to ssh client if paramiko has issues
20:53	I saw some "20 times slower" reports, but they're supposed to have been addressed a couple of years ago
20:53	<vagrantc> i'm pretty sure once the socket was connected, python wasn't running anymore
20:53	<alkisg> Weird
20:54	<vagrantc> but probably easier to test it than go by my memory :)
20:54	<alkisg> Sure, if I can get it to work :)
20:54	I'll need weeks of pam reading before reaching that point
20:54	* alkisg reads https://parallel-ssh.org/post/ssh2-python/ ...
20:56	<alkisg> sftp_read 19.35 sec 1.13 sec x17.12
20:56	ssh2-python is 17 times faster than paramiko in reads...
21:14	<quinox> transfer speed or connection-setup speed?
22:05	kjackal has left IRC (kjackal!~quassel@2a02:587:3105:5d00:91a9:d04a:8358:403e, Ping timeout: 252 seconds)
22:22	<quinox> 17 times is for reading, auth and channel-open are 1.71x and 8.85x
22:22	I make heavy use of Fabric which runs on top of Paramiko
22:27	<vagrantc> i do reacall python-ssh2 was looked at way back when, but had some limitations ... years go by, things change
22:31	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
22:43	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 258 seconds)
22:59	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)