[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
Don Clark dclarkjr@wowway.com
Wed, 3 Jun 2009 00:25:00 GMT
Thanks Brian & Greg. I went with the cygwin approach. I grabbed the redhat version, it seemed to come with openssl and the make commands as the base. Thanks Don On Tue, 2009-06-02 at 20:15 -0400, Greg A. Woods wrote: > At Tue, 2 Jun 2009 13:34:20 -0700, Bryan Stansell <bryan@conserver.com> wrote: > Subject: Re: conserver ? > > > > There isn't direct support for that, but I have seen folks use a script > > (or actual compiled program) as a shell for a user, that then fires the > > console client with the appropriate argument (to get to a specific > > port). That way, when you authenticate with a particular user, it > > automatically runs 'console <foo>' and when you exit, you're logged out. > > I suppose if you name the account the same as the console, you could use > > the username as the argument. There's a 'limited' option in the > > conserver.cf to list users that aren't allowed specific actions, so they > > can't switch to other consoles, invoke local commands, etc (just for > > this purpose). > > > > As for Windows, the current solution is to install cygwin and compile > > conserver for that...it works fine. You just have a little extra > > overhead of the cygwin environment to deal with. > > Personally I would suggest the former, either with or without > configuring sshd and/or a login script to run only the "console" client > program. > > While the ability to run "console" clients on remote systems is fun and > flexible, the security issues can very rapidly get out of control even > with careful use of SSL. Central control right on the conserver host > itself via SSH logins is the easiest to manage, and probably also the > easiest to use too, especially if you already have an SSH client on the > workstations you want to connect to consoles from. >