LTSP 5 is in minimal maintenance mode
The new LTSP is hosted at https://ltsp.github.io

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


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

01:08vagrantc_ has joined IRC (vagrantc_!~vagrant@unaffiliated/vagrantc)
01:54vagrantc_ has left IRC (vagrantc_!~vagrant@unaffiliated/vagrantc, Quit: leaving)
02:52vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
03:25lucascastro 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:57Da-Geek has joined IRC (Da-Geek!~Da-Geek@178.153.171.111)
06:16statler has joined IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de)
06:16Da-Geek_ has joined IRC (Da-Geek_!~Da-Geek@37-186-42-131.ip.as39912.net)
06:19Da-Geek has left IRC (Da-Geek!~Da-Geek@178.153.171.111, Ping timeout: 255 seconds)
06:41kjackal has left IRC (kjackal!~quassel@2a02:587:3105:5d00:c192:76d8:48ce:4723, Ping timeout: 258 seconds)
06:49ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:22kjackal 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:17kjackal has left IRC (kjackal!~quassel@2a02:587:3105:5d00:91a9:d04a:8358:403e, Ping timeout: 258 seconds)
09:18kjackal has joined IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr)
09:19nehemiah has joined IRC (nehemiah!~nehemiah@hs-user-138.wia.cz)
09:30statler has left IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de, Remote host closed the connection)
10:05statler has joined IRC (statler!~Georg@gwrz3.lohn24.de)
10:07Da-Geek_ has left IRC (Da-Geek_!~Da-Geek@37-186-42-131.ip.as39912.net, Read error: Connection reset by peer)
10:08Da-Geek_ has joined IRC (Da-Geek_!~Da-Geek@37-186-42-131.ip.as39912.net)
10:39nehemiah has left IRC (nehemiah!~nehemiah@hs-user-138.wia.cz, Read error: Connection reset by peer)
11:58Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
13:54Da-Geek_ has left IRC (Da-Geek_!~Da-Geek@37-186-42-131.ip.as39912.net, Remote host closed the connection)
15:46adrianor1 has joined IRC (adrianor1!~adrianorg@177.18.48.253)
15:49adrianorg has left IRC (adrianorg!~adrianorg@191.32.101.9, Ping timeout: 250 seconds)
16:18kjackal_v2 has joined IRC (kjackal_v2!~quassel@2a02:587:3105:5d00:91a9:d04a:8358:403e)
16:18kjackal has left IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr, Ping timeout: 240 seconds)
16:24kjackal_v2 has left IRC (kjackal_v2!~quassel@2a02:587:3105:5d00:91a9:d04a:8358:403e, Ping timeout: 258 seconds)
16:25kjackal has joined IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr)
16:52kjackal has left IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr, Ping timeout: 255 seconds)
16:52adrianor1 has left IRC (adrianor1!~adrianorg@177.18.48.253, Ping timeout: 268 seconds)
17:12kjackal has joined IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr)
17:25adrianorg has joined IRC (adrianorg!~adrianorg@177.18.48.253)
17:39kjackal has left IRC (kjackal!~quassel@ppp-2-86-50-93.home.otenet.gr, Ping timeout: 246 seconds)
17:40sutula has left IRC (sutula!~sutula@207-118-151-61.dyn.centurytel.net, Quit: 'sutula has left the building')
17:44sutula has joined IRC (sutula!~sutula@207-118-151-61.dyn.centurytel.net)
17:50kjackal has joined IRC (kjackal!~quassel@2a02:587:3105:5d00:91a9:d04a:8358:403e)
19:42vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 250 seconds)
19:43vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
19:44vagrantc 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:52adrianorg 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:13vsuojanen 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:15vsuojanen 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:24lucascastro 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:25adrianorg 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:38Faith 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:43statler 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:05kjackal 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:31ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
22:43vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 258 seconds)
22:59vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)