Mailing List Archive

idletimeout issues, and kerberos authentication
Hi, this is more a request for feature enhancement than anything else :)

Firstly, the idletimeout seems to be currently one way only. From
conserver to the host/terminal server. Traffic being read by conserver
from the terminal server doesn't seem to trigger a reset of the idle timer.

Could this be changed, or another option be enabled? As it stands we have
terminal servers that timeout after 15 minutes, so have an idletimeout of 10.
However, most of the time, the hosts have actually written to the
console in that time, so the idletimeout isn't required to actually send
its string.

The other useful option would be direct Kerberos support. That way, it
would still authenticate users, but if they had an existing Kerberos
credential a password would not be required. I'm not sure how easy or
hard this would be to do in reality however :)

Many thanks
Pete
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: idletimeout issues, and kerberos authentication [ In reply to ]
On Fri, Sep 09, 2005 at 02:00:32PM +0100, Peter Saunders wrote:
> Could this be changed, or another option be enabled? As it stands we have
> terminal servers that timeout after 15 minutes, so have an idletimeout of 10.
> However, most of the time, the hosts have actually written to the
> console in that time, so the idletimeout isn't required to actually send
> its string.

so, would most term servers reset their disconnect timer when data flows
either way? my first impression was that data had to be sent to the
term server to keep it alive. but if that's not the case, it can
certainly be changed so that the idletimeout doesn't fire until it's
totally quiet.

if anyone can prove that the idle bits work as i expected (data needs to
come into the term server), please let me know. otherwise, i'll just go
on the assumption that data in either direction prevents the term server
from shutting things down and fix things as requested. it certainly
makes sense (well, they both do, but this slightly more).

> The other useful option would be direct Kerberos support. That way, it
> would still authenticate users, but if they had an existing Kerberos
> credential a password would not be required. I'm not sure how easy or
> hard this would be to do in reality however :)

me either. perhaps the PAM hooks would work? i've never tried,
honestly. i'd certainly put any kerberos patches into the distribution.
i don't have an environment to develop and test against (or any
knowledge of the kerberos api).

Bryan
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: idletimeout issues, and kerberos authentication [ In reply to ]
On Fri, 2005-09-09 at 17:06 -0700, Bryan Stansell wrote:
> me either. perhaps the PAM hooks would work? i've never tried,
> honestly. i'd certainly put any kerberos patches into the
> distribution.
> i don't have an environment to develop and test against (or any
> knowledge of the kerberos api).

I think PAM is the best method. With PAM users can add authentication.
Including LDAP, NIS, etc.



_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: idletimeout issues, and kerberos authentication [ In reply to ]
On Fri, Sep 09, 2005 at 05:06:39PM -0700, Bryan Stansell wrote:
> so, would most term servers reset their disconnect timer when data flows
> either way? my first impression was that data had to be sent to the
> term server to keep it alive. but if that's not the case, it can
> certainly be changed so that the idletimeout doesn't fire until it's
> totally quiet.
>
> if anyone can prove that the idle bits work as i expected (data needs to
> come into the term server), please let me know. otherwise, i'll just go
> on the assumption that data in either direction prevents the term server
> from shutting things down and fix things as requested. it certainly
> makes sense (well, they both do, but this slightly more).

Well, I can't speak for any one elses terminal servers.. But as an
experiment.. I telneted to ours after taking it out of conserver
control.. At the timeout period, it disconnected me.

Then, i tried again, but on the host had a while(true) loop running
'echo "keep alive" > /dev/console' every 10 minutes.. The terminal
server session stayed alive.

> me either. perhaps the PAM hooks would work? i've never tried,
> honestly. i'd certainly put any kerberos patches into the distribution.
> i don't have an environment to develop and test against (or any
> knowledge of the kerberos api).

I dont believe PAM would work in this case. It could authenticate
correctly against kerberos with the correct module, but to be
passwordless, the client and server would need knowledge of the
tickets etc.

Many thanks
Pete
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: idletimeout issues, and kerberos authentication [ In reply to ]
here's a patch (against 8.1.12) to fix the idletimeout issue...it'll be in the
next release, but figured some would like it now.

Index: group.c
===================================================================
RCS file: /home/bryan/cvsroot/conserver/conserver/group.c,v
retrieving revision 5.318
diff -c -r5.318 group.c
*** group.c 8 Jun 2005 18:09:40 -0000 5.318
--- group.c 24 Sep 2005 20:26:31 -0000
***************
*** 2520,2525 ****
--- 2520,2535 ----
CONDDEBUG((1, "DoConsoleRead(): read %d bytes from fd %d", nr,
cofile));

+ if (nr > 0) {
+ pCEServing->lastWrite = time((time_t *)0);
+ if (pCEServing->idletimeout != (time_t)0 &&
+ (timers[T_CIDLE] == (time_t)0 ||
+ timers[T_CIDLE] >
+ pCEServing->lastWrite + pCEServing->idletimeout))
+ timers[T_CIDLE] =
+ pCEServing->lastWrite + pCEServing->idletimeout;
+ }
+
if (pCEServing->type == HOST && pCEServing->raw != FLAGTRUE) {
/* Do a little Telnet Protocol interpretation
* state = 0: normal

Bryan
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users