[02:44] <sbalneav> Evening all
[03:08] <stgraber> evening sbalneav
[04:53] <sbalneav> stgraber: Got a minute? I'd like an opinion.
[05:14] <stgraber> sbalneav: sure
[05:15] <stgraber> sbalneav: sorry for the delay, was writting a blog post for the bug day
[05:23] <sbalneav> NP, so I've been hacking around tonight with pam-sshauth.
[05:24] <sbalneav> I think I've settled on what I want to do, but I just want an opinion as to if this seems sane or not.
[05:24] <sbalneav> So, we use libssh for authentication, and handling the password change.
[05:25] <sbalneav> but once we've done the auth, rather than duplicate a bunch of code, seems to me the best thing to do would be to spawn off just an ssh, using the password we've just gotten.
[05:26] <sbalneav> seeing as how it's a pam module, we shouldn't need to worry about the ssh's password expiring, since if it DID expire, we would have just handled that.
[05:26] <sbalneav> so theoretically, by the time we drop to handling the session part, we can just do the ssh hostname, an pass the password we've gotten.
[05:27] <sbalneav> and the spawned ssh will handle the x11 and command socket stuff.
[05:32] <stgraber> hmm, wouldn't that block PAM in some way ?
[05:33] <stgraber> it'd perfectly be fine to have a module option to keep the SSH in the background and have a master socket created
[05:33] <stgraber> so we can then use that to do whatever we want and that will still act just like a regular PAM module
[05:34] <stgraber> so if someone uses that module for authentication on his laptop against one of his company's ssh server, he'll still get a local console and not a remote one and if wanted he'd also get access to a SSH control socket so he doesn't need to authenticate again for that SSH server.
[21:09] <nixternal> http://blog.lydiapintscher.de/2010/01/10/kde-edu-irc-meeting-and-release-parties/
[21:10] <nixternal> KDE-Edu team is having an irc meeting at 20:00 UTC on January 14th in #kde-edu here on Freenode for those that might be interested