next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects
Index of Subjects Hi Kevin... am I correct in assuming that although this visitor account will not be accesible from a telnet connection... you will still have a "guest" account that will allow a telnet session to apply for an account and explore public portions of the community network...? I think our discussions around this function included collecting the login: and password: ...checking the login name to prevent chaining guest logins and then trying to establish the telnet session... maybe this will come up at the technical workshop later today (Wednesday)... Alternatively...I wondering if we should give some thought to the name of such an account... it would be helpfull for travellers if the "visitor" account had the same name across partner systems. With the comming of bilingual service we have now use "visiteur" as our French "guest" account. Does this suggest a need to have four guest accounts? guest/visiteur visitor/??? david potter O n Tue, 24 Jun 1997, Kevin Traas wrote: > Date: Tue, 24 Jun 1997 14:20:24 -0300 > From: Kevin Traas <ktraas@uniserve.com> > To: csuite-dev@chebucto.ns.ca, "Matthew R. Brown" <m_brown@uniserve.com> > Cc: hscom@valleynet.bc.ca > Subject: Re: Visitor's Telneting > > Just to add a comment regarding this feature (I'm the one who wrote it with > input from several others). > > Right now, the user "visitor" is allowed to access our system either via > dialup or telnet from elsewhere on the internet. However, access _to_ this > account from the internet is for demonstration and/or evaluation purposes > only and will be disabled in a "production" environment. > > Reasons for this include: > > 1. The whole point of having this "visitor" account is to allow visitors > to our community to use our PATS (or otherwise) to dial into our system and > then access their "home" system for e-mail, etc. i.e. These visitors will > only be using our local dial-up numbers. > > 2. Allowing someone to connect to a system and then telnet elsewhere > without having to enter a password (i.e. no user validation) is typically a > bad idea. 'Net hackers use this method as an attempt to hide their trail > (they bounce from system to system making it hard to find the originating > connection). Therefore, incoming telnet connections should not be allowed > to use the visitor account. (This is the reason guest isn't allowed access > to telnet.) > > The package Matt is bringing to TC97 doesn't have any login restrictions; > therefore, keep this in mind when/if you install it. The included README > provides info on how to contact us to receive the "production" version with > these restrictions in place. > > Matt Brown wrote: > > > I approached our tech staff and they came up with a simple but effective > method for visitors to use our system to telnet back to their own community > network. Here is how it works: > > > > - A visitor dials in with a terminal program to 702-1138. > > > > - Logs in as 'visitor' > > > > - Selects the community network from the menu list > > > > (the visitor is telnetted to that system) > > > > - Log in under your own name and password > > > > - when you log off your system you are logged off ours. > > > > Anyone wishing to have a peek can telnet into ValleyNet at > > > > 206.12.160.1 and login as visitor. > > > > I will be bringing this module to the CSuite Workshop at TC97.. >
next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects